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

[Nick Lewycky]

Bill Wendling wrote:
> On Apr 9, 2012, at 3:38 PM, Rafael Espíndola<rafael.espindola at gmail.com>  wrote:
>
>>> 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.
>>
> And what if the user would like zed to stick around for debugging purposes? What recourse do they have?
>
>> 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.

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

Nick

>>> 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.
>>
> It's only redundant when internalize is the default. If not, then it's necessary and useful.
>
>>> There may be more reasons.
>>
>> What are they?
>
> I supplied two. Please address them first before demanding more examples.
>
>> 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?
>
> -bw
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>