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

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Tue May 3 15:18:42 PDT 2016


joker.eph added a comment.

Note: I haven't looked at the patch, or the LTO implementation in lld, but my take on the current state of the gold plugin is that we expose far too much in the linker. I understand that the libLTO API was not nice, but I think the solution implemented in the gold plugin is terrible because it does not expose any generic API. 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.

For instance any call to "setLinkage" should never happen in a linker-specific code.

Feel free to implement it as you want in `lld`, but I don't want to be bound by any "external" logic as I have been in the past with the gold plugin (i.e. I'll break lld and won't try to fix it).


================
Comment at: ELF/LTO.cpp:75
@@ -70,2 +74,3 @@
   PMB.OptLevel = Config->LtoO;
+  PMB.ModuleSummary = Summary;
   PMB.populateLTOPassManager(LtoPasses);
----------------
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.


http://reviews.llvm.org/D19351





More information about the llvm-commits mailing list