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

[Mehdi AMINI via llvm-commits]

joker.eph added a comment.

> > > 

> 

> > 

> 

> > > 

> 

> > 

> 

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


It is not clear to me: why can't you implement CFI in ThinLTO without ThinLTO in lld? 
Is CFI is tied to lld in particular? I thought it is in production with Gold, even though admittedly I haven't followed closely all that stuff.

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


The stable libLTO interface is not going away soon AFAIK, and we'll have to live with this for some time. The LTOCodeGenerator is terrible, and the ThinLTOCodeGenerator is not any better! Except maybe that it exposes a smaller API surface, and less constrained (for instance the number of object files produced does not have to match the number of inputs).
So do I think the ThinLTOCodeGenerator should be extended? No, on the contrary, it should be made a lot thinner by refactoring it, leaving in the end only the minimum possible that I'd expect a linker plugin to be: i.e. a bridge between the information needed by the ThinLTO logic and the linker itself.
The fact that the gold-plugin was developed as a monolithic blob is unfortunate, the fact that lld didn't bother refactoring any API with the gold-plugin seems wrong to me.

> 

> 

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


This will necessarily put some constrains on the FunctionImporter for instance, I already hit this with the GoldPlugin. This is what I mean by "I don't want to signup for maintaining this". 
Of course I could go the way the gold-plugin and lld went: just for the FunctionImporter into ThinLTOCodeGenerator, but I don't think that how LLVM is usually developed.


http://reviews.llvm.org/D19351