[PATCH] D19351: ELF: Add initial ThinLTO support.

[Peter Collingbourne via llvm-commits]

pcc added a comment.

In http://reviews.llvm.org/D19351#420588, @joker.eph wrote:

> In http://reviews.llvm.org/D19351#420587, @pcc wrote:
>
> > > The proper solution should be in my opinion to have a "LTOCodeGenerator" (and/or a "ThinLTOCodeGenerator") that exposes an appropriate interface to the linker, that would be shared by lld, gold, etc.
> >
> >
> > Maybe, but I'm not sure that we can know what the right interface should be without working implementations in multiple linkers.
>
>
> There *is* an LTO implementation that is working in multiple linker through libLTO (and gold that went with a dedicated plugin).


I'm mostly talking about ThinLTO. ld64 is the only linker that uses ThinLTOCodeGenerator, to my knowledge.

> > 

> 

> > 

> 

> > > I'll break lld and won't try to fix it

> 

> > 

> 

> > 

> 

> > That doesn't really seem reasonable to me. We all have a responsibility to keep the bots green.

> 

> 

> That seems reasonable, but the conclusion on my side is that I then disagree with implementing ThinLTO in lld at all at this point as it is adding duplicating code that should not be there in the first place, and will just prevent progress in LLVM (the gold-plugin is already "technical debt")


Not having ThinLTO in lld is already preventing progress in LLVM for me. It prevents me from being able to implement the extensions I need for CFI, for example.

If you're saying that you think that it would be better to extend ThinLTOCodeGenerator with what lld/gold/etc requires, I disagree, as I think it's premature to do that, especially since it's tied to the stable libLTO interface.

> Just to clarify my position: ThinLTO needs some coupling with the linker on multiple aspects, if the interface is not clearly defined and the logic is not shared, it means that evolving the function importer requires to change each linker plugin implementation, duplicating the same logic, which is a no-go IMO (this is the current state of ThinLTO in LLVM with some logic unfortunately duplicated between ThinLTOCodeGenerator and the gold-plugin).


I agree that in the long term each linker should be using some well defined interface to ThinLTO, but I think we don't know what that interface should be yet. That's part of the reason why I'm implementing this directly first.

Besides, it's not a lot of logic, and as I already mentioned, I want to keep the API surface here small.


http://reviews.llvm.org/D19351