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

[Teresa Johnson via llvm-commits]

tejohnson added a comment.

In http://reviews.llvm.org/D19351#420655, @pcc wrote:

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


Currently the support in gold-plugin for ThinLTO is pretty minimal, as it is here with the lld patch: read the per-module indexes, combine them, launch backend threads (which do the renameModuleForThinLTO and pass down the combined index). Most of the code in the gold-plugin is the thread launching/management.

What I would like to do is to refactor some of the handling out of libLTO, as noted earlier, but want to wait until the distributed backend communication is in place.


================
Comment at: ELF/LTO.cpp:75
@@ -70,2 +74,3 @@
   PMB.OptLevel = Config->LtoO;
+  PMB.ModuleSummary = Summary;
   PMB.populateLTOPassManager(LtoPasses);
----------------
joker.eph wrote:
> rafael wrote:
> > This cause the new lld to depend on Linker::linkModules, which should really not happen.
> > 
> > Mehdi, you are working on having the function import pass use just the ir mover, correct? What is the next step in that?
> > 
> I believe the only reason I didn't go all the way was because the "Linker" handles some specific things about comdat that are not implemented in ThinLTO (we don't have comdat information in the summary). And since we don't have comdat on Darwin, I'm not use to work with them. 
> I don't know if Teresa has this in her TODO list.
For ld64/libLTO Mehdi has the support in to determine which linkonce values are needed so the lazy symbol linking is not used. However, we need that on the gold path, along with comdat handling which will need more info in the summary (added to my TODO list). I only want to do this once I have the distributed backend communication in place (D19636) so that there can be a single mechanism to communicate this and any linkage changes to the backends/importer. Then some of the handling that is in libLTO can be refactored out and used on all paths. Eventually this will lead to the function importer being able to use IRMover directly. 


http://reviews.llvm.org/D19351