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

[John McCall]

On Jun 27, 2012, at 10:10 PM, Rafael Espíndola wrote:
>> Weak linkage across shared-library boundaries is a serious launch-time
>> performance problem, because every symbol that's weakly exported from
>> a dynamic object has to be checked for potential coalescing with symbols
>> from every other dynamic object.  This is why the Darwin dynamic linker
>> does not coalesce strong symbols with weak ones, and this is why we would
>> like to not have to export function symbols at all in the common case that
>> they're only called (or placed in vtables) within a dynamic library.
> 
> Yes, trying to implement this is exactly how I found this bug :-(
> 
> But if the functions are emitted with weak_odr only in the TU where
> the vtable is, there will be only one DSO where they are defined and
> the coalescing will be trivial (ignoring the transition period where
> we have DSO built with older compilers, but it would still not be any
> worse than what we have now).

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.

(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.)

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.

>> Devirtualization, on the other hand, is a fairly minor optimization when
>> it does not create inlining opportunities.
> 
> Sure, and we can inline with available_externally or linkonce_odr
> functions, so the optimization opportunities we have are orthogonal to
> allowing undefined references in cases like this one.

I'm just noting that, AFAIK, neither gcc nor clang is actually capable of
doing this right now, and fixing that would also restore the inline-function
invariant without permanently compromising our ability to hide symbols
that are referenced by strong v-tables.

John.