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

[John McCall]

On Jun 28, 2012, at 8:51 AM, Rafael Espíndola wrote:
>> 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.

Yes.

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

Yeah, I believe that dynamic linkers in practice optimize under the
assumption that symbols won't be defined by multiple DSOs.  They still
have to do linear work, though.

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

It also shouldn't be possible if the function is inline.  Conversely, there's
nothing stopping us from devirtualizing if the function *isn't* inline — in
that case, there really is a translation unit which is required to export that
symbol strongly, and in almost all cases there's a direct language way
to get some other translation unit to emit a reference to that symbol.

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

Thank you.

John.