[llvm-dev] ThinLTO and linkonce_odr + unnamed_addr

[Reid Kleckner via llvm-dev]

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