[PATCH] D20268: Resolution-based LTO API.

[Mehdi AMINI via llvm-commits]

mehdi_amini added inline comments.

================
Comment at: include/llvm/LTO/LTO.h:103
@@ +102,3 @@
+  /// needed to supply an owning LLVMContext for the IRObjectFile.
+  static ErrorOr<std::unique_ptr<InputFile>> create(MemoryBufferRef Object,
+                                                    LTO &Lto);
----------------
pcc wrote:
> mehdi_amini wrote:
> > mehdi_amini wrote:
> > > I'm not sure, it seems easy to turn it around: "you are the one proposing an API that is targeted for performance reason with a specific use case (and client) in mind, so the burden should be on you to justify it if you want this to get it in.", otherwise write a cleaner API.
> > Running ld64 on the 701 bitcode files that make an LTO build of llc (X86 only), and exiting right before the LTO optimizer starts, i.e. after the LTO merge happens (best of 10 times, on a 4-cores laptop):
> > 
> > - Parallel resolution (dedicated context, double parsing): 7.362s
> > - Sequential resolution (shared context, single parsing): 8.834s
> > 
> > 
> Thanks. To me it isn't clear how much of that is due to parsing as opposed to parallel resolution, but I can accept that this would simplify clients. So I suppose I can try to make the change you suggested.
I chatted with Duncan and thought you may be interested by some history: his recollections of the original motivation for parsing in separate context was not parallelism but the amount of things that leaks to the context, while the modules wouldn't be used if they come from static archives anyway.
Especially at that time global metadata were not lazyloadable.


https://reviews.llvm.org/D20268