[polly] Memory access based dependency analysis

[Johannes Doerfert]

I don't think a single reduction in a statement without anything else needs
this memory access based dependency tracking.
However, I found it easier to order the patches this way. Furthermore, the
patch which will cause the need for this kind of
Analysis is big enough on its own and I don't really see the point in
combining them (or changing the order and producing wrong code in between).

So what is the plan now? Do we agree on the need for this patch? Can I
commit it now? If so, we should also consider the next patch as it will
bring the compilation time back to normal.

--

Johannes Doerfert
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation


-----Original Message-----
From: Tobias Grosser [mailto:tobias at grosser.es] 
Sent: Tuesday, June 24, 2014 3:22 PM
To: Johannes Doerfert
Cc: llvm-commits at cs.uiuc.edu; 'Sebastian Pop'
Subject: Re: [polly] Memory access based dependency analysis

On 24/06/2014 23:59, Johannes Doerfert wrote:
> If we allow reductions and other "statements" in one SCoP statement a 
> situation as explained below could arise.
>
> Situation:
> Assuming we want to allow more than one reduction in a statement, we 
> still do not want to parallelize the last loop as it is not (easily) 
> parallelizable.

I can see that we want this.

> However, if we only look at dependences on statement level we see a 
> reduction read-write-pair and the corresponding reduction dependences
> template:
>     { Stmt_for_body[i0] -> Stmt_for_body[1 + i0] : i0 >= 0 and i0 <= 
> 1022 } and might assume we can remove these dependences from the 
> overall set of dependences for this statement.
 >
 >
 >
> While this is true for a loop nest with only sum and also for 
> something
> like:
>     for (i) {
>        A[i] = A[i] + A[i-2];
>        *sum += i;
>     }
> It is not true/allowed for the last loop nest shown below.

Interesting. So it seems the test cases that show the benefit of per-access
dependence computation all have more than just a single reduction. Is this
right?

Is there any benefit of per-memory-access tracking in the current code base?
Can we show it in a test case?

Tobias