[llvm] r188188 - Misc enhancements to LTO:

[Shuxin Yang]

On 8/13/13 9:37 PM, Nick Lewycky wrote:
> I don't think such comparison is precise.  For app with networking 
> lib, the "braid" reside at app side because the app define the behavior.
>
>>         For linker+libLTO, I believe the "brain" should reside at
>>         libLTO side, as it is far more complicate (although our
>>         current implement is bit simple).
>>
>>
>>     I'm afraid I don't agree. We can agree to disagree on this point,
>>     it isn't necessary for us to agree here to make forwards progress.
>     Such discussion will be open-ended. I don't like to waste
>     bandwidth over here. It is not my focus
>     at all.  Maybe you can understand that point after you try to make
>     some infrastructure level
>     change to the lto. If you OSX, you will see that. If you don't,
>     grab a Linux machine, try to implement
>     that feature on Linux+gold but *WITHOUT* touching any bit the
>     tool/gold/*.
>
>
> Does 
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090202/073164.html 
> count? tools/gold/* didn't exist when I started.
Unfortunately, not.

You are working on a simple and clean APIs provided by gold linker.
How about try to achieve what I'm try to achieve without touching these 
bits?

The difficulty is how dance under the existing interface, not how to 
bridge two interfaces.

>
> Look, I didn't make up this rule. I'm trying to tell you, as a new 
> contributor, that the rule already existed and you should be aware of it.
>
> Here's an old example of Chris mentioning the rule that changes to the 
> C ABI are not allowed (and yes, libLTO's API is part of the C API):
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090720/081858.html . 
> I don't think this is the first time it was mentioned either, but I 
> wasn't able to find a better example with a minute of searching.

I did not *change* "C ABI", I *add* API.

>     Currently, we ignore the I/O issue about LTO, can you imagine what
>     kind of APIs we need in future
>     to improve the I/Os. And how can magically maintain such backward
>     compatability? libLTO is
>     potentially very complex state-machine.
>
>     Why not let linker to expose its interface, and let plugin (LTO)
>     to work with them. Isn't that easier.
>     I don't understand you think exposing interface from LTO to linker
>     is better. Such linker is tightly
>     bound to a compiler, dedicated to compiler. In order to maintain
>     that linker, engineer needs in-depth
>     knowhows about compiler and linker. I don't see why it is better.
>
>
> Let me try to restate what you said in my own words, so we can make 
> sure I understood it. You want llvm-lto to be its own program, and the 
> system linker should be a plugin that llvm-lto loads?
Why the hack there are so many confusion.

I want a stand-alone, decoupled liner, just like gold which talk with 
llvm-lto on gold's interface, not lto_xxx().
i.e. the llvm-lto in my mind would be current libgold + libLTO.


> Sure. It's a way to let the compiler and the compiler-provided LTO 
> plugin collaborate, via "flags" (really any string with limited 
> punctuation).
>
> But that assumes the linker will be run by the compiler, which isn't 
> always true. We want llvm lto to work as a drop-in replacement for the 
> existing tools, and sometimes existing build systems will run ld 
> directly. (Yes, gold will search known paths on the system to find the 
> plugin, it doesn't require a flag.)

Then the existing weird build system have to understand the these flags. 
No other way around.
I don't see why a linker have  to work with one compiler.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130813/b8967ca3/attachment.html>