[patch] First step to fix pr11866 during LTO

[Nick Kledzik]

On Sep 5, 2013, at 1:33 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> On 5 September 2013 16:04, Nick Kledzik <kledzik at apple.com> wrote:
>> Rafael,
>> 
>> When would the linker call this new lto_codegen_add_symtab_symbol() function?  What is the semantic difference between it and lto_codegen_add_must_preserve_symbol()?
> 
> The difference is the same as the two lists in the internalize level
> that bill asked about (see
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130902/186896.html,
> I will include something like that in the comments.).
> 
> In the plugin interface exposed by gold this corresponds to
> PREVAILING_DEF_IRONLY_EXP (the api is documented in
> http://gcc.gnu.org/wiki/whopr/driver).

I read that previous post, but the difference is still to subtle for me ;-)

The linker currently calls lto_codegen_add_must_preserve_symbol() on symbols that LTO should not optimize away (such as F).  In your scenario,  you imply that that linker would call the new function lto_codegen_add_symtab_symbol() on G “just to put in the symbol table”.  I’m not sure what that means.  Then you say the LTO can reason and decide to omit G, even though the linker called lto_codegen_add_symtab_symbol() on it.  So, what is the point of lto_codegen_add_symtab_symbol()?

-Nick