[llvm-commits] [llvm] r154124 - /llvm/trunk/tools/lto/LTOCodeGenerator.cpp

[Rafael Espíndola]

> Okay. Let's discuss this. What are the benefits of running internalize by default as opposed to running it via a command-line option?

The example I posted before:

void foo(void) { }
__attribute__((visibility("hidden"))) void zed(void) { }
int main(int argc, char *argv[]) {
  foo();
  zed();
  return 0;
}

The function zed should be internalized. The function foo should or
should not be depending on -export_dynamic on ELF. Not sure about the
semantics on Mach-O, but the linker should know it.

As Nick pointed out, changing this is also breaking API compatibility
with old versions of libLTO.

> If we go the `-fwhole-program' option, it's more in line with what people might expect from LTO (those coming from gcc-land especially). There could be other, subtle reasons why a programmer may not want to run the internalize pass. Keeping around functions to call when debugging code springs to mind. They may not want to mess with export lists for these functions (so no internalize), but would like them to go away when shipping the product (so running internalize).

LTO and internalize are beneficial when not in whole-program mode. The
main use case I have in mind is building firefox which is a big shared
library. -fwhole-program is completely redundant with a good plugin
interface like the one we have.

> There may be more reasons.

What are they? Do note that you example breaks at -O3 -Wl,-dead_strip,
so this in not specific to running internalize.

> -bw
>
>

Cheers,
Rafael