[patch] First step to fix pr11866 during LTO

Rafael EspĂ­ndola rafael.espindola at gmail.com
Wed Sep 4 22:13:07 PDT 2013


> Hi Rafael,
>
> This looks very much like the "external names" interface that's already in place. I'm assuming that there's a fundamental difference between the two? Is it only so that you can differentiate between symbols whose addresses don't leak?

There is a fundamental difference. The "external names" list is a list
of symbols that we absolutely must provide. The new list of "symbol
table" symbols we can omit if the LLVM knows it is safe. I do agree
that with two lists "external names" is a bit generic. Maybe
"externally used" would be better.

For an example of the difference, consider a dynamic library being
built from two TUs. Translation unit A in compiled to native
(ELF/MachO/COFF) and translation unit B is compiled to IL. Translation
unit A has a copy of inline function F. The translation unit B has a
copy of the inline functions F and G.

Lets say the linker decides to go with the copy of F in B. This means
that LLVM absolutely must produce F in the object file it passes to
the linker, otherwise we will have an undefined reference. For G the
situation is different. The linker tells us that it wants that
function just to put on the symbol table. Not because some native file
depends on it. With this information LLVM can now reason that since
the function is a linkonce_odr and its address doesn't leak, it can be
omitted. Any other shared library needing this function will have a
copy of it.

Cheers,
Rafael



More information about the llvm-commits mailing list