[llvm-dev] ThinLTO and linkonce_odr + unnamed_addr

[Mehdi AMINI via llvm-dev]

Isn't #2 actually changing the behavior by changing the visibility while
llvm.compiler_used seems actually closest to current behavior to me?

The visibility hidden would break comparison of function as you mentioned,
which is not the case with auto-hide if I didn't miss anything.

-- 
Mehdi


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

> I agree with Teresa, we should probably do #2 to preserve behavior for now.
>
> On Wed, Feb 7, 2018 at 9:34 AM, Teresa Johnson via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Steven,
>>
>> I'd prefer not to inhibit importing. I am also concerned about putting
>> these symbols in the llvm.compiler_used (I don't recall earlier discussion
>> around this, but it seems like it could have effects on optimization as you
>> mention).
>>
>> What are the downsides of #2 (adding visibility hidden)? We already do
>> this when promoting internal linkage to external due to importing. I'm not
>> an expert on how this would affect link semantics.
>>
>> Thanks,
>> Teresa
>>
>> On Tue, Feb 6, 2018 at 5:35 PM, Steven Wu <stevenwu at apple.com> 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
>>>
>>
>>
>>
>> --
>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>> 408-460-2413 <(408)%20460-2413>
>>
>> _______________________________________________
>> 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/fc2a906a/attachment.html>