[LLVMdev] [PATCH] parallel loop metadata

Pekka Jääskeläinen pekka.jaaskelainen at tut.fi
Wed Jan 30 02:35:07 PST 2013


Thank you all for comments,

On 01/30/2013 11:22 AM, David Tweed wrote:
> In a personal capacity I'm quite interested in the issues of producing from a
> high-level language some LLVM IR which is labelled with vectorization info
> (including potentially actually reordering data in memory).
>
> | I don't have any objections. I think the only requirement is that the
> semantics are clearly defined.
>
> I think that's very important :-)
...
> to be integrated. So I'd like at least a way to say "this is what I _really_
> want the vectorizer to assume" in such metadata.

I agree. Thus, let's start with the 'parallel' semantics first, not
the vague ones.

A conclusion of some kind for me to update the patch:

1) Rename the loop branch metadata back to llvm.loop.parallel.

I'll add a definition of its semantics (as comments to Loop::isParallel()):

No loop-carried dependency checking at all can be assumed with this
type of loops. If the compiler does some analysis to improve the performance
or other reasons, it still can, but is not required to do so.

2) Keep the memory accessing instruction metadata as it is.

At least until something better appears.

The rationale is that when the parallel loop is marked this way (both a
branch metadata and memory instruction metadata required for isParallel()),
missing metadata in some of the memory instructions due to some
optimizations that do not propagate the data correctly does not cause
breakage (lead to assuming a now-sequential loop is still parallel).
It just potentially makes the parallel loop non-parallel which should be
safe.

In addition, the scheme of augmenting memory accesses with parallelism
info can be extended to retain the parallelism data over loop unrolling
too (useful for instruction scheduling). Also, e.g., retaining the restricted
pointer data across function inlining might be able to use a similar
mechanism.

We can improve the actual marking mechanism gradually because
the parallelism check will be wrapped inside Loop::isParallel().

Is this OK?

-- 
--Pekka




More information about the llvm-dev mailing list