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

Peter Collingbourne via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 21 13:20:30 PDT 2016


pcc added inline comments.

================
Comment at: include/llvm/CodeGen/LTOBackend.h:67
@@ +66,3 @@
+  /// (ThinLTO) the module, before modifying it.
+  ModuleHookFn PreOptModuleHook;
+
----------------
mehdi_amini wrote:
> pcc wrote:
> > mehdi_amini wrote:
> > > What is the Task "ID" at this point? This would be a task that will not codegen in the case of a parallel backend?
> > > What is the Task "ID" at this point? 
> > I'm not sure what you are asking here. The task ID generally stays consistent across the whole pipeline.
> > 
> > > This would be a task that will not codegen in the case of a parallel backend?
> > Do you mean a distributed backend? In that case, none of the hooks will be called for ThinLTO tasks other than the combined module hook. I will document that.
> I meant the LTO parallel codegen: after merging the IR you will call this hook with a tuple <task-ID, module> that will never go through the codegen.
In this case the task id would be 0, and it would be split into tasks 0..N-1.

Although task 0 will end up using a different module for codegen (i.e. whichever partition happened to be assigned task id 0), the module provided to the hook at this point is still significant, as any changes made to the module (e.g. adding common symbols for gold) will be reflected in the partitions.

================
Comment at: include/llvm/LTO/Resolution/LTOBackend.h:71
@@ +70,3 @@
+  /// data structures. A module hook will never be called from multiple threads
+  /// with the same task ID, or the same module.
+  ///
----------------
mehdi_amini wrote:
> The thread safety in LLVM is at the LLVMContext level, not the module level.
Yes, but I wanted to describe the intention here should we ever relax the thread safety in LLVM. (For example, if we ever made it safe for multiple code generation threads to operate on a single module, the guarantee here would be stronger than the default guarantee.)


http://reviews.llvm.org/D20268





More information about the llvm-commits mailing list