[PATCH] D17066: libLTO: add a ThinLTOCodeGenerator on the model of LTOCodeGenerator.

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 12 10:16:16 PST 2016


joker.eph added inline comments.

================
Comment at: lib/LTO/ThinLTOCodeGenerator.cpp:297
@@ +296,3 @@
+  Mang.getNameWithPrefix(Buffer, &GV, false);
+  if (PreservedSymbols.count(Buffer)) {
+    Keep.insert(GV.getName());
----------------
tejohnson wrote:
> joker.eph wrote:
> > tejohnson wrote:
> > > So the linker must place any external symbols with references from other modules in this set, right? I see that you added a comment that suggest that to the thinlto_codegen_add_must_preserve_symbol interface. Might want to add something to that effect here as well.
> > Any symbols with reference from other *non thinlto* modules to be exact.
> > I'll add a comment here.
> So an external symbol with a reference from another thinlto module would not be in this set and would be internalized? I realize that you are remembering the original linkage and later setting it back. But what happens in the mean time with the internalize and globalDCE passes? Couldn't they cause one of the symbols referenced from another thinlto module to be internalized and then eliminated, since you don't see those references here?
You're right! 
What has to be inside are functions that are cross-referenced as well.
I was confused because I move the set of preserved symbols from "per module" to be on the code generator (i.e. one for all), but it is the union of the individual sets (if they still existed). 


http://reviews.llvm.org/D17066





More information about the llvm-commits mailing list