[Polly] Isl AST reduction pragmas [V2]

Tobias Grosser tobias at grosser.es
Thu Jun 19 08:48:27 PDT 2014


On 19/06/2014 17:28, Johannes Doerfert wrote:
>> There may be a test case (I did not create one), where the scheduler
>> decides for whatever reason to transform the code from:
>>
>> for(i = 0; i < n; i++
>> S1:  A[0] +=
>>
>> to:
>>
>> for(i = 0; i < n; i+=2
>> S1a:  A[0] +=
>>
>>
>> for(i = 1; i < n; i+=2
>> S1b:  A[0] +=
>>
>> In this case, there will be no loop carried dependences any more, as
>> dependences now go always back and forth between S1a and S2b. So we may
>> incorrectly detect the new loops as parallel.
> Why incorrectly?
>
> 1) Reordering the reductions is exactly what we allow by removing the reduction
>     dependences before scheduling.

That is correct. The possible reordering of the scheduler is not the 
problem. This is exactly what we would like to enable.

> 2) Marking them as parallel clearly break the reduction dependences, thus we
>     need (and would now) introduce privatization.

Why?

The dependences for the first program are:

{S[i] -> S[i+1]}

The dependences for the second program are the same, but the schedule is
modified to:

{S1[i] -> [0, i]: i % 2 = 0; S1[i] -> [1, i]: i % 2 = 1}

If we now check the last loop for parallelism, we remove all dependences 
that do not both start and end in the same loop. In this case, this 
means we will remove all dependences. So we detect parallelism even 
before introducing any privatization.

> My reasoning is that we have the privatization dependences to restrict the
> scheduler only to legal transformations.

Right.

 >  The "is parallel test" in the end is
> only concern with the if and now also the how to parallelize loops, like the
> need to privatize.

Right. In this case, we would not detect the need for privatization.

> I'm still convinced that the current solution does not
> produce invalid code in any way, but only privatizes without need in case of
> loop reversals.

Why would you privatize data in a loop that does not carry and reduction 
dependences? I assume we will not. Consequently, the generated code is 
incorrect.

Tobias






More information about the llvm-commits mailing list