llvm dev - Feb 2021 - Questions about annotations

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210204/b77abc52/attachment.html>

> On Feb 4, 2021, at 00:07, Kaylor, Andrew <andrew.kaylor at 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
<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 <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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210204/8616039c/attachment.html>