[LLVMdev] Parallel Loop Metadata
Tobias Grosser
tobias at grosser.es
Mon Feb 11 14:58:50 PST 2013
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.
All the best,
Tobias
[1] http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html
More information about the llvm-dev
mailing list