[PATCH] D29104: Add !associated metadata.

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D29104#655699, @eugenis wrote:

> In https://reviews.llvm.org/D29104#655685, @mehdi_amini wrote:
>
> > In https://reviews.llvm.org/D29104#655669, @eugenis wrote:
> >
> > > In https://reviews.llvm.org/D29104#655651, @mehdi_amini wrote:
> > >
> > > > I mean the specific optimizations that won't happen that motivate not using llvm.compiler.used.
> > >
> > >
> > > I'm not sure. Perhaps, link time devirtualization? Without this, ASan would have to add every single global to llvm.compiler.used, which would make globaldce not do anything at all.
> >
> >
> > It'll still operate on every functions. And this is what happens on Darwin today.
>
>
> Yes, and it works fine. But on Linux we can do better.


I'm missing what is platform specific in this?

> Isn't it possible that GC-ing of virtual tables would kill class methods, which can in turn kill more virtual tables and allow devirtualizing of more call sites?

Possible, we'll have to consider the benefit of "advanced optimizations" in the context of ASAN builds though, and balanced this with the cost.

>>> If anything, it is bad for the object file size.
>> 
>> Linker will garbage collect.
> 
> Object file size matters, too.

I'll ask to see the numbers before moving forward with this motivation.

> 
> 
>> 
>> 
>>> The real reason is w/o the GlobalDCE change !associated has strange semantics - it protects a global from linker GC, but only if said global survives compiler GC. I don't see how that is useful.
>> 
>> I'm not convinced at all by the `!associated` at this point, in particular I haven't seen anything it does which is different from what is done on Darwin.
> 
> Darwin is not a problem here. ELF is.
>  On Darwin, ASan uses the "live_support" linker hack:
>  https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L1680

Sure, I know about this: https://github.com/llvm-mirror/llvm/commit/090f75dc839cbe1d94c8445bf8fabd0f19309f25

> SHF_ASSOCIATED is the proposed ELF implementation of roughly the same concept. We need a way to represent it in the IR.

Sure, I get that, but what is fundamentally different between the Darwin live_support section and SHF_ASSOCIATED? 
This is likely the main piece of information that I'm missing right now.

I also don't think that adding metadata that are "correctness related" is a good thing in general.


Repository:
  rL LLVM

https://reviews.llvm.org/D29104