[llvm-dev] ThinLTO and linkonce_odr + unnamed_addr

[Mehdi AMINI via llvm-dev]

Hi,

My understanding is also that there should be no semantic difference
between linkonce_odr and weak_odr other than the discardable aspect.

So I don't understand why llvm.compiler_used would be a problem here? It
seems to me that linkonce_odr + llvm.compiler_used is exactly like
weak_odr, isn't it?

Cheers,

-- 
Mehdi


2018-02-07 10:29 GMT-08:00 Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org>:

> There should be no semantic difference between linkonce_odr and weak_odr,
> except that weak_odr is non-discardable. Why doesn't the autohide
> optimization work just as well on weak_odr + unnamed_addr as linkonce_odr +
> unnamed_addr?
>
> On Tue, Feb 6, 2018 at 5:35 PM, Steven Wu via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I recently found that thinLTO doesn't deal with globals that has
>> linkonce_odr and unnamed_addr (for macho at least) because it prohibits the
>> autohide optimization during link time.
>>
>> In LLVM, we tagged a global linkonce_odr and unnamed_addr to indicate to
>> the linker can hide them from symbol table if they were picked (aka,
>> linkonce_odr_auto_hide linkage). It is very commonly used for some type of
>> Tables for c++ code in clang for example.
>> However, thinLTO is promoting these symbols to weak_odr + unnamed_addr,
>> which lose the property. As a result, it introduces unnecessary weak
>> external symbols and weak external are not good for performance on darwin
>> platforms.
>>
>> I have few proposed solutions for this issue but I don't know which one
>> works the best for none macho platforms and other LTO clients like lld.
>>
>> 1. Use llvm.compiler_used.
>> As far as I know, the linkage promote are just there to keep the symbol
>> through internalize and codegen so adding them to compiler used should
>> solve this issue. I was told that there was some objections to do that in
>> the first place. Is it because the globals added to compiler used is
>> ignored by the optimizer so they cannot be internalized and they cannot be
>> optimized away? This works well for the case I am looking at because c++
>> VTable can't really be optimized and for darwin platforms because we can
>> rely on ld64 to do dead_stripping if needed.
>>
>> 2. Add visibility hidden when promote linkonce_odr + unnamed_addr.
>> Well,this doesn't really preserve the link semantics, but neither does
>> promoting linkonce_odr to weak_odr. The global will still end up in the
>> symbol table but at least it isn't external so it doesn't come with a
>> performance cost.
>>
>> 3. We can teach function importer that it cannot just reference to
>> linkonce_odr + unnamed_addr symbols without importing them. I have some
>> thoughts about how to do this so I can propose something if people are
>> interested going down this route. I am expecting at least add an entry in
>> the global summery and change the cost of importing symbols that references
>> to linkonce_odr + unnamed_addr symbols.
>>
>> 4. As a temporary fix, just targeting at the VTables for c++. We can put
>> a special case for global constants that uses this linkage so they are
>> never promoted and their parents are never imported into other modules. The
>> benefit for inlining global constants is very minimal and I don't think we
>> are doing it currently.
>>
>> Let me know if any of those solutions work for other LTO client.
>>
>> Thanks
>>
>> Steven
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/e8e75982/attachment.html>