[PATCH] D18986: [ThinLTO] Prevent importing of "llvm.used" values

[Mehdi AMINI via llvm-commits]

joker.eph added a comment.

In http://reviews.llvm.org/D18986#404419, @tejohnson wrote:

> In http://reviews.llvm.org/D18986#404415, @joker.eph wrote:
>
> > In http://reviews.llvm.org/D18986#404380, @tejohnson wrote:
> >
> > > In http://reviews.llvm.org/D18986#404324, @joker.eph wrote:
> > >
> > > > Also, could we promote and rename while keeping a private alias with the old name for these globals?
> > >
> > >
> > > No, because we could import inline assembly from two different modules, each containing a reference to a local 'myvar', and the two imported uses within the imported inline assembly need to each see the correct corresponding promoted global.
> >
> >
> > There are two things:
> >
> > 1. "llvm.used" symbols (that are referred *from* inline assembly)
> > 2. Functions that contains inline assembly themselves.
> >
> >   I was referring to the first one while you are mentioning the second ones right?
>
>
> I'm talking about the first one, with regards to the symbol that is renamed/promoted. The functions containing inline assembly matter just in the sense that it is through importing them that you provoke the renaming of the symbols used in the inline assembly (and referenced on the llvm.used).
>
> E.g. if you look at the test case I added here, let's say there was a second file inlineasm2.ll that looks like:
>
> @myvar = internal constant i8 1, align 1
>  @llvm.used = appending global [1 x i8*] [i8* @myvar], section "llvm.metadata"
>
> define void @bar(i64* %v) #0 {
> entry:
>
>   %v.addr = alloca i64*, align 8
>   store i64* %v, i64** %v.addr, align 8
>   %0 = load i64*, i64** %v.addr, align 8
>   call void asm sideeffect "movzbl     myvar(%rip), %eax\0A\09movq %rax, $0\0A\09", "=*m,~{eax},~{dirflag},~{fpsr},~{flags}"(i64* %0) #1
>   ret void
>
> }
>
> I.e. this is the same as Input/inlineasm.ll, except that we have a function bar instead of foo (inline assembly is the same, and each uses a local variable @myvar). If we import bar() into the main module as well (assume main() is changed to call both foo() and bar()), then we need to promote/rename both copies of myvar. The imported inline assembly copies need to refer to the correct renamed/promoted copy of myvar. It isn't possible to set up a private alias in main()'s module from myvar to both of the renamed/promoted myvars. Peter had some ideas (see the link in the patch summary) for some new assembly directives to handle this, but that is a longer-term fix that is quite a bit more extensive.


If you import `bar()` it mean you are not considering my 1) but the 2) above (this is a function that *contains* inline asm and not a function that is *referenced* by inline asm).


http://reviews.llvm.org/D18986