[LLVMdev] Parallel Loop Metadata

[Hal Finkel]

----- Original Message -----
> From: "Tobias Grosser" <tobias at grosser.es>
> To: "Nadav Rotem" <nrotem at apple.com>
> Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu>
> Sent: Monday, February 11, 2013 4:58:50 PM
> Subject: Re: [LLVMdev] Parallel Loop Metadata
> 
> On 02/11/2013 10:31 PM, Nadav Rotem wrote:
> > Now that we have a better understanding of the proposal for using
> > per-instruction metadata, I think that we need to revisit the
> > "single metedata" approach (Pekka's original suggestion).
> 
> Following Andrew's comments we understood that Sebastian's proposal
> causes issues with inlining and unrolling. It seems we all agree that
> his proposal is not an option we can go with.
> 
> Besides that, from my point there are still two options:
> 
> 1) llvm.loop + nothing else
> 
> 2) llvm.loop + llvm.mem
> 
> Is there any specific reason you only want to revisit option 1)?
> 
> I have the feeling option 2) does not work for you, but I don't yet
> understand your reasons. The last comment from you was: "I don't
> fully
> understand the semantics of this metadata and I am not sure why we
> need
> it. And even if we do need it, I think that it would require too many
> passes to change". Is this still your opinion or could Pekka's
> explanation help you to understand this better?
> 
> > Reg2mem is indeed a problem, but the loop vectorizer can solve this
> > in more than one way (detect or fix). The example pass that you
> > mentioned below (the instrumentation pass), can be taught to
> > handle the parallelism pragmas.
> 
> When LLVM metadata was introduced [1], one of the core principles
> was:
> 
> "]...] we don't want the optimizers to have to know about metadata."
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> By requiring instrumentation passes like the one I explained to take
> the llvm.loop meta-data into account, we do not follow this principle
> any more. To my knowledge for instruction level meta-data, this would
> be
> the first case where we ignore this core principle.
> 
> Are you suggesting we now require passes to reason about meta-data to
> maintain correctness?
> 
> > Can you think of other passes that we will need to modify ?
> 
> I could probably imagine other passes. Though, my main concern are
> passes that I do not understand. We would e.g. need to reason about
> the thread-sanitizer, address-sanitizer and memory-sanitizer passes.
> What about the (path) profiling passes? Would we need to inspect all
> of
> them?
> 
> I am really not a fan of adding more meta-data than necessary.
> However,
> I have the feeling there are some good reason to believe llvm.loop
> meta-data may not be enough. And given the fact that with tbaa
> meta-data
> has proven that a per memory-access meta-data can work nicely,
> llvm.mem
> may be a feasible option.

I agree with this. We should err on the side of safety even at the cost of larger IR. Relying on other passes to drop metadata on loop backedges, even if those passes are making (seemingly) completely-unrelated changes is asking for trouble; and in this case, trouble means miscompiles. Also, the changes to support propagating this metadata in existing passes are well defined: just grep for all places where TBAA metadata is handled. Some refactoring may be in order, but that is not a bad thing.

 -Hal

> 
> All the best,
> Tobias
> 
> [1] http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>