[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