[cfe-commits] [patch][pr13124] Use strong symbols for functions that go in a strong vtables

[Rafael Espíndola]

> The actual act of coalescing is trivial — it's just writing a different address
> into a relocation table that generally has to be dirtied anyway if you're
> emitting position-independent code (and on Darwin, nearly everything is
> position-independent by security fiat).  The problem is that the dynamic
> linker has to do extra work linear in the number of weak symbols.  In C++,
> that tends to be a very large number, and almost all of that work is wasted.

Just to clarify, the "number of weak symbols" is the total number in
all the DSOs, right? So if the weak symbol "foo" is defined in 5 DSO,
that counts as 5, not 1.

If that is the case, producing a single weak copy would still help.
Not as much as making them hidden everywhere of course.

> (The linux dynamic linker does a lot of this work for *all* symbols with
> non-hidden visibility.  That is *insane*, and it causes serious load performance
> problems with dynamic libraries that have not been carefully optimized to
> export a minimal set of symbols.  This is a serious overhead even when
> the work is only done lazily, which is not possible for symbols referenced
> from vtables.)

Yes, that is why software ends up having to use -fvisibility=hidden
and other, nastier, hacks :-(

> Moreover, the language itself is designed to give us a guarantee that
> every translation unit that needs an inline function will be able to emit it.
> I am very reluctant to introduce rules that make that guarantee more
> complex.

This would prevent devirtualization in cases where we can produce an
available_externally vtable but not the function itself, but I agree
that this is a corner case.

The optimization I implemented that found this was marking as hidden
constants and functions that are both linkonce_odr and unnamed_addr.
This is based one a LTO optimization that newer versions of gold
allow, so I think I will be able to reproduce the link problem with
gcc's LTO plugin.

I will try that and start a new thread (ccing gcc folks) with the
result and summary.

> John.

Cheers,
Rafael