[polly] Memory access based dependency analysis

Johannes Doerfert jdoerfert at codeaurora.org
Tue Jun 24 14:59:56 PDT 2014


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.
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.

--

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 2:51 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:44, Johannes Doerfert wrote:
> As I said, I don't want to stick to the statement only contains one 
> reduction limit.

I understood that and I got (almost) convinced already by the need to handle
multiple reductions.

I am not yet 100% sure what the best approach for dependency handling is.

> In such a case we can have a statement which induces exactly the same 
> dependences as a reduction like:
>
> for (i) {
>      A[i] = A[i] + A[i-1];
>      A[i-1] = A[i] + A[i-2];
> }
>
> Printing analysis 'Polly - Calculate dependences' for region: 
> 'for.cond => for.end' in function 'onlyA':
>          RAW dependences:
>                  { Stmt_for_body[i0] -> Stmt_for_body[1 + i0] : i0 >= 
> 0 and
> i0 <= 1022 }
>          WAR dependences:
>                  {  }
>          WAW dependences:
>                  { Stmt_for_body[i0] -> Stmt_for_body[1 + i0] : i0 >= 
> 0 and
> i0 <= 1022 }
>          Reduction dependences:
>                  {  }
>
>     for (i)
>        *sum += i;
>
> Printing analysis 'Polly - Calculate dependences' for region: 
> 'for.cond => for.end' in function 'onlySum':
>          RAW dependences:
>                  {  }
>          WAR dependences:
>                  {  }
>          WAW dependences:
>                  {  }
>          Reduction dependences:
>                  { Stmt_for_body[i0] -> Stmt_for_body[1 + i0] : i0 <= 
> 1022 and i0 >= 0 }
>
>    for (i) {
>      A[i] = A[i] + A[i-1];
>      A[i-1] = A[i] + A[i-2];
>      *sum += i;
>    }
>
> Printing analysis 'Polly - Calculate dependences' for region: 
> 'for.cond => for.end' in function 'AandSum':
>          RAW dependences:
>                  { Stmt_for_body[i0] -> Stmt_for_body[1 + i0] : i0 <= 
> 1022 and i0 >= 0 }
>          WAR dependences:
>                  {  }
>          WAW dependences:
>                  { Stmt_for_body[i0] -> Stmt_for_body[1 + i0] : i0 <= 
> 1022 and i0 >= 0 }
>          Reduction dependences:
>                  {  }
>
>
> Is that a valid reason to use memory access based tracking?

This is an interesting test case. However, you did not explain what the
expected output would be here? At least at the moment we would not detect
reduction dependences with and without memory access based tracking. Do you
expect reduction dependences to be detected?

Cheers,
Tobias







More information about the llvm-commits mailing list