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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
