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

[Peter Collingbourne via llvm-commits]

pcc added a comment.

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

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


CFI with regular LTO works in all linkers, but the ThinLTO version will be based on lld because of some missing features in the gold plugin interface. See this thread: https://groups.google.com/forum/#!topic/llvm-dev/OWmVaxNrIxo

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


It's not so much a matter of "not bothering" as the fact that it didn't really seem worth it due to the small amount of code needed, and it would just introduce another abstraction layer that people would need to understand.

But maybe there's some simple interface that we could implement now that could be shared at least between the gold plugin and lld. I suppose in the future in order to allow the interface to be used by ThinLTOCodeGenerator we may want to add caching or other features there, so it doesn't seem too unreasonable to introduce a place for those features to be added for all linkers. Let me see if I can come up with something.


http://reviews.llvm.org/D19351