[patch] First step to fix pr11866 during LTO

Rafael EspĂ­ndola rafael.espindola at gmail.com
Wed Oct 2 18:24:46 PDT 2013

> Yes, I think it would work. The semantics would be
> * If lto_codegen_preserve_global_symbols was not called, there is no
> symbol table to worry about (executable and no -export-dynamic). LLVM
> should keep only the symbols passed to
> lto_codegen_add_must_preserve_symbol and internalize everything else.
> * If lto_codegen_preserve_global_symbols is called, LLVM knows that
> the globals are going to a symbol table. It must preserve everything
> passed to lto_codegen_add_must_preserve_symbol as before. It can
> internalize globals only if knows they can be dropped from the symbol
> table.

Hi Nick,

Sorry for the long delay. I went on vacations and it took me some time
to catch up with code review.

An awesome development while I was out is that Tom Roeder added a test
driver for LTO, so now the patch has a testcase which should make it
more clear what is being implemented.

Thinking about your idea of adding lto_codegen_preserve_global_symbols
I decided that it would be better to get some numbers. I took the
largest "shared library" I had at hand: clang with -export_dynamic. On
linux gold currently asks for 22922 symbols to be preserved. I applied
the attached hack-timeit.patch to test how long it takes for us to get
the internalized combined module. On my machine (2010 iMac),  the time
is 0.08s, so despite large number of calls and the
std::map<std::string>, internalize in general is not too slow. For
scale, the verifier takes about 1s. Parsing the bitcode file takes 5s
(the file is 118 MB).

With this patch, the only symbol that gold doesn't mark as "symtab
only" is main. This lets llvm drop 445 symbols. This is not a lot, but
the current patch doesn't even check if an address is taken (it just
uses the unnabed_addr attribute).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hack-timeit.patch
Type: application/octet-stream
Size: 2894 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131002/19d9946c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symtab.patch
Type: application/octet-stream
Size: 16600 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131002/19d9946c/attachment-0001.obj>

More information about the llvm-commits mailing list