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

[Rafael Espíndola]

>> 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.
>>
> And what if the user would like zed to stick around for debugging purposes? What recourse do they have?

I am fine with adding a debug option.

>> As Nick pointed out, changing this is also breaking API compatibility
>> with old versions of libLTO.
>>
> LTO hasn't really worked well in the past. I'm not convinced that this is a show-stopper.

It was not perfect , but I was able to bootstrap clang and build
firefox with it. Do we really have to break backwards compatibility to
add a debug option?

>> 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.
>>
> It's only redundant when internalize is the default. If not, then it's necessary and useful.

Sorry, can you expand this? -fwhole-program lets the user  tell the
compiler that there will be no external references to this compilation
unit. The linker and the object file semantics know the same. What is
the gain in disabling the internalize pass and then adding
-fwhole-program?

>>> There may be more reasons.
>>
>> What are they?
>
> I supplied two. Please address them first before demanding more examples.

This change broke a working system. Seems like a high bar for a regression.

>> Do note that you example breaks at -O3 -Wl,-dead_strip,
>> so this in not specific to running internalize.
>>
>
> Wait...it breaks non-LTO builds?! How?

The same way as with LTO almost. Instead of the linker telling us that
we can remove the symbol, it removes the symbol by itself.


> -bw
>

Cheers,
Rafael