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

[Peter Collingbourne via llvm-commits]

pcc added a comment.

In this version of the patch I started exercising the test harness so you can see what that looks like. As previously mentioned I also moved the code to a separate library (lib/LTO/Resolution) so we can depend on it from clang.

I started working on the clang side backend, but there's a hairy output stream yak to shave there, so it'll take a little more time.


================
Comment at: include/llvm/CodeGen/LTOBackend.h:120
@@ +119,3 @@
+/// If GV's linkage is linkonce, change it to weak so that it won't be DCE'd.
+void upgradeLinkage(GlobalValue *GV);
+
----------------
pcc wrote:
> mehdi_amini wrote:
> > This is a strange API at this level. 
> > And the naming is very generic for what the description says it does.
> Yes, agree. After I finish the reorganization I mentioned earlier, I want to move this API to a library-internal header.
I ended up folding this into the caller on the regular LTO side, as ThinLTO linkage upgrades now go via the module summary index.

================
Comment at: include/llvm/LTO/LTO.h:90
@@ +89,3 @@
+  comdat_alias = 1,
+  unable_to_find_target,
+};
----------------
pcc wrote:
> mehdi_amini wrote:
> > I think some doc may be nice for the enum values (I have no idea what is `comdat_alias` right now).
> Will do.
I ended up removing this error category and just using StringError for errors produced by this module.

================
Comment at: include/llvm/LTO/LTO.h:93
@@ +92,3 @@
+
+const std::error_category &lto_category();
+
----------------
pcc wrote:
> mehdi_amini wrote:
> > doc (public API in public header)
> Will do
See above


http://reviews.llvm.org/D20268