[patch] First step to fix pr11866 during LTO

[Nick Kledzik]

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

>> 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()?
> 
> If neither  lto_codegen_add_must_preserve_symbol or
> lto_codegen_add_symtab_symbol is called, the symbol is sure to be
> internalized. If  lto_codegen_add_must_preserve_symbol is called, it
> will *not* be internalized. If lto_codegen_add_symtab_symbol is
> called, it *may* be internalized, depending on semantic knowledge that
> LLVM has, but the linker doesn’t.


I understand what you are saying from llvm’s point of view, but to my original question:
> When would the linker call this new lto_codegen_add_symtab_symbol() function? 


Does it call it on every weak symbol which it did not call lto_codegen_add_must_preserve_symbol() on?  If so, then what is the point.  The LTO interface should be able to infer that.

-Nick


> 
> Consider:
> 
> -------------------------------
> void f();
> struct foo {
>  typedef void (foo::*mptr)();
>  virtual mptr zed();
>  void bar() {
>  }
>  __attribute__((noinline)) void baz() {
>    f();
>  }
>  virtual void bah() {
>  };
> };
> foo::mptr foo::zed() {
>  baz();
>  return &foo::bar;
> }
> -----------------------------
> 
> without LTO we get a shared library with foo::bar, foo::baz, foo::bah
> and foo::zed. With this patch and LTO (with gold), foo::bah is
> dropped. The reason is that the gold plugin calls
> lto_codegen_add_symtab_symbol. LLVM then reasons with information
> passed in by clang that the address of foo::bah is not important
> (unnamed_addr since it is virtual) and every TU that uses it has a
> copy (linkonce_odr because ti is inline).
> 
> The gold plugin also calls lto_codegen_add_symtab_symbol for baz and
> bar. In a followup patch I want to make internalize noticed that the
> address of baz is not used, and it can be dropped too. It will never
> drop bar, since its address *is* important, and we need it to be in
> the symbol table in case any code compares the address.
> 
> Cheers,
> Rafael