What to do with LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN?

Rafael Espíndola rafael.espindola at gmail.com
Thu Oct 24 13:05:05 PDT 2013


On 24 October 2013 14:14, Nick Kledzik <kledzik at apple.com> wrote:
> 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.

Yes. Not that all of these patches only change the LTO side. In fact,
I have also emailed you a patch for the non LTO side (subject:
"Produce .weak_def_can_be_hidden for some linkonce_odr value") which
causes clang to start emitting .weak_def_can_be_hidden.

> 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?

The analysis itself is dead simple: check if the address is taken.

The problem is that any function could be taking the address, so we
have to read theirs bodies to check. This is something that llvm could
maintain as a flag or even metadata. Since it is not common for a pass
to introduce a use of the address of a global that had no uses before,
this should be fairly simple to keep updated.

I decided to benchmark the impact of the "keep.patch". The patch takes
the linking of all of clang with gold and plugin-opt=emit-llvm from
0m19.149s to 0m20.140s.

Given that

* The perf impact is not that bad.
* It can be optimized by having clang compute a "address used" flag.
* Using LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN reuses logic the linker
uses  for the non-lto case.
* If we use it we can simplify the LTO API.

I am back to preferring keep.patch. Are you OK with it?

> -Nick

Cheers,
Rafael




More information about the llvm-commits mailing list