[PATCH] D20268: [wip] Resolution-based LTO API.

[Mehdi AMINI via llvm-commits]

joker.eph added inline comments.

================
Comment at: include/llvm/LTO/LTO.h:27
@@ +26,3 @@
+  unsigned FinalDefinitionInLinkageUnit : 1;
+
+  /// The definition of this symbol is visible outside of the LTO unit.
----------------
D20217 on declaration would work, but my point was rather that there is no "symbol resolution" here that helps with setting this on decl.


================
Comment at: include/llvm/LTO/LTO.h:139
@@ +138,3 @@
+
+  /// This type defines a file callback. The file callback passed to run() is
+  /// used to add a native object that already exists as a file on disk, for
----------------
Overall I see the generalization through an arbitrary grouping of input IR files in partitions. Pure ThinLTO is 1 input file per partition, while pure LTO is 1 partition with every file. Any combination seems possible to me in between. For instance we planned to try to have as many partition as cores on the machine, group files in a somehow balanced way in these partitions, and perform ThinLTO across these partitions.

The issue right now for what you call "de-internalization" is that the only thing you have is `VisibleToRegularObj` and this does not tell you about references between LTO and ThinLTO.
The implementation I made in ld64 makes the linker aware of the split between files that are in the LTO group on one side and in the ThinLTO group on the other side. The information provided by the linker is not `VisibleToRegularObj` but  `VisibleOutsideOfThisGroup` and is provided separately for the LTO group and the ThinLTO group.
While easy to implement on top of the existing LTO in the linker, I'd like to avoid repeating this here and not exposing the LTO vs ThinLTO to the linker. That said having to recollect all the def/undef for every file and compute `VisibleToAnotherLTOGroup` is not appealing either.




http://reviews.llvm.org/D20268