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

[Rafael Espíndola]

> Since my name has been evoked ... :)
>
> I have a serious concern with this API in the libLTO public interface. I
> don't think we should talk about 'internalize' in the API, it should be
> worded in terms of what we're trying to achieve, such as how the resulting
> binary will be used (ie., must export symbols for a plugin, will be linked
> into a standalone executable, to produce a .so file, performing .o -> .o
> relinking, etc.) -- assuming that's what this feature is even implementing.
>
> I have to admit I don't understand the motivation and without having
> focussed on this thread, it feels like a bug that internalize wouldn't work
> as-is. The only time we shouldn't run it is if it wasn't going to have any
> effect anyhow, or to work around other bugs (note: I'm counting things like
> untracked symbol usage due to inline asm or the backend lowering to libcalls
> as a bug, which when fixed would render this new switch obsolete).

Those are good points and I agree with them. Assuming there is a use
for internalizing nothing (even if for debugging),  I suggest that we
get it  by

* Keeping the current default. Changing it breaks existing code and it
is a reasonable default to have.
* Renaming lto_codegen_set_whole_program_optimization to
lto_codegen_must_preserve_all_symbols.

As an optimization, lto_codegen_must_preserve_all_symbols can be
implemented by disabling the internalize pass.

> Nick

Cheers,
Rafael