[llvm-dev] Questions about annotations

[Kaylor, Andrew via llvm-dev]

Hi everyone,

 

I’ve recently discovered a problem with reading LLVM bitcode that was produced by older versions of LLVM. Specifically, if the older bitcode file contains calls to llvm.var.annotations or llvm.ptr.annotations, I get an error because the number of arguments to these intrinsics was changed. I’ve filed a bug for this (https://bugs.llvm.org/show_bug.cgi?id=49006) and I’m working on a patch to auto-upgrade the older IR.

 

The extra argument was introduced in this patch: https://reviews.llvm.org/D88645

 

In looking closer at that patch, I see that an extra member was also added to the initializer structures for the llvm.global.annotations value. Here I have a problem that I’m not entirely sure how to handle. Specifically, the Annotation2Metadata pass, which was introduced here (https://reviews.llvm.org/D91195) expects the llvm.global.annotations values to have four members, but after the patch above clang creates initializers with five members.

 

The top-of-trunk LLVM code will happily read a module containing four member initializers, and having read that module the Annotation2Metadata pass will create annotation metadata for it. Unfortunately, it appears that Annotation2Metadata will not create annotation metadata for the llvm.global.annotations with five-member initializers that are generated by the latest version of clang. So, I don’t know what the correct behavior here is.

 

Should the BitcodeReader auto-upgrade the four-member initializers to five-member initializers with a null pointer in the fifth field? Or should Annotation2Metadata handle either type of initializer?

 

I don’t know enough about how these things are being used to confidently answer.

 

Thanks for any help anyone can offer.

 

-Andy

[Florian Hahn via llvm-dev]

On Feb 4, 2021, at 00:07, Kaylor, Andrew <andrew...@intel.com> wrote:

Hi everyone,

 

I’ve recently discovered a problem with reading LLVM bitcode that was produced by older versions of LLVM. Specifically, if the older bitcode file contains calls to llvm.var.annotations or llvm.ptr.annotations, I get an error because the number of arguments to these intrinsics was changed. I’ve filed a bug for this (https://bugs.llvm.org/show_bug.cgi?id=49006) and I’m working on a patch to auto-upgrade the older IR.

 

That sounds good.

The extra argument was introduced in this patch: https://reviews.llvm.org/D88645

 

In looking closer at that patch, I see that an extra member was also added to the initializer structures for the llvm.global.annotations value. Here I have a problem that I’m not entirely sure how to handle. Specifically, the Annotation2Metadata pass, which was introduced here (https://reviews.llvm.org/D91195) expects the llvm.global.annotations values to have four members, but after the patch above clang creates initializers with five members.

 

The top-of-trunk LLVM code will happily read a module containing four member initializers, and having read that module the Annotation2Metadata pass will create annotation metadata for it. Unfortunately, it appears that Annotation2Metadata will not create annotation metadata for the llvm.global.annotations with five-member initializers that are generated by the latest version of clang. So, I don’t know what the correct behavior here is.

 

Should the BitcodeReader auto-upgrade the four-member initializers to five-member initializers with a null pointer in the fifth field? Or should Annotation2Metadata handle either type of initializer?

 

Given that the pass was only added quite recently, I think just updating it to support the 5 field version would be fine, if we can pick it on the 12.x release branch.

Cheers,

Florian

[Kaylor, Andrew via llvm-dev]

The patch for auto-upgrading the intrinsics is here: https://reviews.llvm.org/D95993

 

Florian, I’m not sure I understand your answer about llvm.global.annotations precisely enough to implement a change there, so let me ask more specific questions.

 

1. Should the auto-upgrader modify the @llvm.global.annotations initializer list to add a fifth member to the structure?
2. Should the Annotation2Metadata pass accept both 4- and 5-member initializers or only 5-member?
3. Is it important to handle this for the 12.0 release?

 

My concern in the second question is that while I know clang will generate the 5-member initializer, I don’t know if there are other front ends using the annotations and it seems that nothing in the IR verifier is enforcing this. Should there be something in the Verifier checking this?

 

Also, the language reference wasn’t updated when the fifth argument was added to the annotation intrinsics and llvm.global.annotations isn’t documented at all. I don’t know enough about this to update the documentation, so I won’t be attempting that.

 

To be completely honest, I don’t have a lot of time to spend on this. My primary interest is in making sure we maintain backward compatibility for the bitcode. I’m trying to get that fixed while investing as little time as necessary in learning the details of how the annotations are used.