On Jun 29, 2012, at 11:40 AM, Rafael Espíndola wrote: >> But that's pervasively true in C++ — the linker has to eliminate duplicates >> all the time. Idiomatic C++ code ends up plunking down hundreds, if >> not thousands, of inline functions in every single translation unit. This is >> already a massive burden for linking C++ programs, particularly in debug >> builds. Adding a few extra symbols when the optimizer determines that >> it can devirtualize, but declines to inline, is essentially irrelevant. >> >> In fact, it is particularly unimportant because it's very likely that this >> duplicate >> will be in the same DSO as the vtable. That means that the first solution >> imposes some extra work on the static linker alone (but again, only when >> devirtualizing a call to a function we don't want to inline!) while >> preserving >> our ability to reduce work for the dynamic linker (since calls do not rely >> on address equality of the function across translation units). The second >> solution is an irrevocable guarantee that every symbol mentioned in >> a strong vtable *must* be exported to the whole world. >> >> Also recall that these symbols can already be emitted in arbitrary >> other translation units — we cannot change the ABI to say that these >> symbols are *only* emitted in the file defining the v-table. > > I would just like to point out that the ABI could says that they only > *need* to be emitted in the file with the vtable, but yes, for a long > time it would have to support the symbols showing up in other > translation units produce by older compilers.
There's no "for a long time" here. The ABI does not allow us to emit these symbols with non-coalescing linkage. We're not going to break ABI just because people didn't consider a particular code pattern when they hacked in devirtualization through external v-tables. John.
