[patch] First step to fix pr11866 during LTO

Rafael Espíndola rafael.espindola at gmail.com
Thu Sep 5 14:01:32 PDT 2013


> 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.

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




More information about the llvm-commits mailing list