[llvm-commits] [patch][pr11866] Drop linkonce_odr symbols from the symbol table when safe

[Rafael Espíndola]

The attached patch fixes PR11866.

My original idea on how to fix it (see comment 3 in that bug) is a bit
hard to implement. The problem is that the LTO infrastructure reports
an undefined reference when it sees a declaration.  For example, a
file with just

declare void @foo()

is going to show up as having an undefined reference. Simple cases
like this should be simple to filter out, but we also have to handle
declarations used only in available_externally "definitions" like the
ones in pr13124. Doable, but I think I found an easier way.

Gold's plugin api was updated some time ago to let the plugins know
that a symbol is not used from any ELF file, but gold would still put
it in a symbol table if present. In this case the plugin is free to
drop the symbol if it knows it doesn't need to go in a shared object's
symbol table. That is what this patch does.

In detail:

* The LTO code is updated to record which linkonce_odr functions  and
constants don't have their address taken (or have an unnamed_addr
flag).
* The plugin still reports linkonce_odr symbols to gold.
* The plugin doesn't force LTO to keep symbols that gold tells us
would be needed only for the symbol table and have been marked as
noted above.

When linking clang with LTO (and -export-dynamic,  so it is
effectively a DSO), the number of linkonce_odr symbols goes from 1907
to 63. Of these 63

* 61 are typeinfo names, so we do need to keep them visible since
their address is compared.
* 2 are linkonce_odr globals, which we also have to keep visible to
observe mutations.

CCing nleycky for opinions on the plugin changes and the linker guys
to know if this is also a reasonable way to go for lld.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr11866.patch
Type: application/octet-stream
Size: 4565 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120616/ccc8eea3/attachment.obj>