What to do with LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN?

[Nick Kledzik]

Rafael, 

The can-be-hidden concept was invented a few years back for non-LTO compiles to work with a new darwin linker feature.  I was meant to be an attribute on inline (weak) functions which the optimizer decided to not inline (but could have) and the address of that inline function was not taken in that translation unit (unnamedAddr).  In the linker, after coalescing together all copies of a weak function, if all had the can-be-hidden attribute, the linker would change the visibility on it from default to hidden.  The goal being that by default final linked images would have far fewer weak external symbols, which slow down launching.

The darwin linker side has supports this, but the darwin clang side never finished (rdar://7819925), although the LinkOnceODRAutoHideLinkage linkage type was added.

With that background, I don’t like the drop.patch because it is a step backwards.  

What is the inefficient analysis that would need to be done?  Is it something the front end could have done and set the linkage type to LinkOnceODRAutoHideLinkage?  

-Nick

On Oct 23, 2013, at 11:34 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> Hi Nick,
> 
> With the recent addition of a dso symbol list to the LTO api
> LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN seems redundant with it. There
> seems to be three possibilities of what to do about it
> 
> One option is to keep it and move the dso list over to it. That is
> instead of the linker telling LTO which symbols are for a DSO symbol
> table, LLVM tells the linker which symbols can be hidden and the
> linker tells LLVM which of those to keep. This is implemented in the
> keep patch.
> 
> At first I thought this would the best option, since the new apis are
> still not in a llvm release it would be possible to just remove the
> redundancy. The probably fatal problem with this approach is that for
> LLVM to tell the linker which symbols can be hidden, it has to run
> analysis on the file and to do that it has to
> MaterializeAllPermanently, which is quiet inefficient.
> 
> Another option is to drop it. This is implemented in drop.patch. This
> is simple, but may cause some users to miss on optimizations until
> they start using the dsolist.
> 
> And the last option is that if it is too early to drop it, we may as
> well add a bit to it. The safe patch marks linkonce_odr unnamed_addr
> symbols with LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN. This is safe
> since we don't need to materialize function bodies to see the linkage
> and the unnamed_addr attribute.
> 
> Cheers,
> Rafael
> <keep.patch><drop.patch><safe.patch>