[LLVMdev] [PATCH] parallel loop awareness to the LoopVectorizer

Tobias Grosser tobias at grosser.es
Tue Jan 29 00:51:21 PST 2013

On 01/28/2013 12:58 PM, Pekka Jääskeläinen wrote:
> Hi,
> Attached is a patch which uses a simple "parallel_loop" metadata attached
> to the loop branch instruction in the loop latch for skipping
> cross-iteration
> memory dependency checking in the LoopVectorizer. This was briefly
> discussed
> in the email thread "LoopVectorizer in OpenCL C work group
> autovectorization".
> It also converts the "min iteration count to vectorize" to a parameter so
> this can be controlled from the command line.

Hi Pekka,

I was a little bit fast in my last email. I would like to discuss the 
test cases I want to see a little bit more. I am especially interested
to see that the meta data is robust in case of transformations.

Assuming we have something like;

# ignore assumed dependences.
for (i = 0; i < 4; i++) {
    tmp1 = A[3i+1];
    tmp2 = A[3i+2];
    tmp3 = tmp1 + tmp2;
    A[3i] = tmp3;

Now I apply for whatever reason a partial reg2mem transformation.

float tmp3[1];

# ignore assumed dependences. // Still valid?
for (i = 0; i < 4; i++) {
    tmp1 = A[3i+1];
    tmp2 = A[3i+2];
    tmp3[0] = tmp1 + tmp2;
    A[3i] = tmp3[0];

Is the meta data now still valid or how do we ensure the invalid meta 
data is removed?

I have the feeling it may be necessary to link the loop as well as the 
accesses for which we can ignore dependences together and mark the whole 
construct as "this set of memory accesses does not have dependences 
within the mentioned loop". Like this, the introduction of additional 
memory accesses which may very well introduce dependences that we need 
to preserve, can be easily detected. The parallelism check would now be: 
"In case the llvm.loop.ignore_assumed_deps meta-data is found in a loop 
header _and_ all memory accesses in the loop are referenced by this 
meta-data, the loop is parallel. If there is a memory
access that does not reference the ignore_assumed_deps meta-data, we
can not assume anything about the loop.


More information about the llvm-dev mailing list