[llvm-dev] ThinLTO and linkonce_odr + unnamed_addr

[Reid Kleckner via llvm-dev]

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