[Polly] Generating code for changed memory accesses

Johannes Doerfert jdoerfert at codeaurora.org
Mon Jul 28 11:04:18 PDT 2014


Let's assume we have:

     for (i = 0; i < N; i++)
S:     A[i] = 3;

Initially our Scop looks like:
  Domain: { S[i] : i >= 0 and i <= N-1 }
  Write:
     { S[i] -> Memref_A[i] : i >= 0 and i <= N-1 }

Now we prevectorize (and change the scattering/domain but not the access relations!):
  Domain: { S[o, i] : exists (e = floor((o)/4): 4e = o and o <= i and o >= -3 + i and i >= 0 and i <= N-1) }
  Write:
     { S[i] -> Memref_A[i] : i >= 0 and i <= N-1 }

Now we can either apply the scattering to the access relation when we generate code or not.

If we do:
  The access relation will look like:
            { S[o, i] -> Memref_A[i] : exists (e = floor((o)/4): 4e = o and o <= i and o >= -3 + i and i >= 0 and i <= N-1)  }
  Which is fine but if N was a compile time constant less then 4 (e.g., 3) the isl ast codegen will not generate code for the "o-dimension" and the schedule of the isl_ast looks different from the one we have e.g. in ScopInfo:
           dump(ScopInfo->getSchedule()) =>             { S[i] -> S[o, i] : exists (e = floor((o)/4): 4e = o and o <= i and o >= -3 + i and i >= 0 and i <= 2) }
           dump(isl_ast_build_get_schedule(..)) =>  { S[i] -> [i] : and i >= 0 and i <= 2) }
   Now the access relation domain has 2 dimensions but the IslAst schedule has only one output dimension, a missmatch which will cause isl_ast_build_get_access_from... to fail.

If we don't and N is not a compile time constant less then 4:
  The access relation will look like:
       { S[i] -> Memref_A[i] : i >= 0 and i <= N-1 }
  But the schedule (both in ScopInfo and the one of the IslAst) will have two output dimensions and the isl_ast_build_get_access_from... call will fail.

Do you see the problem?

P.S.
It looks like we once we create the pw_multi_aff from the access relation the "singleton" dimensions "become visible":
	The AccessRelation after we remove constant dimensions and the tuple id for the example above:
  	   { [i0, i1] -> MemRef_B[i1] : exists (e0 = floor((i0)/4): 4e0 = i0 and i1 >= 0 and i1 <= 2 and i1 >= i0 and i1 <= 3 + i0) }
                The isl_pw_multi_aff we get from this:
	    { [i0, i1] -> MemRef_B[(i1)] : i0 = 0 and i1 >= 0 and i1 <= 2 }
               And the schedule in the IslAst build:
	   { Stmt_for_body[i0] -> [i0] : i0 <= 2 and i0 >= 0 }

P.S.
I try to change the patches tonight,.. or tomorrow,.. but no promises.

--

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: Monday, July 28, 2014 10:27 AM
To: Johannes Doerfert; 'Johannes Doerfert'
Cc: 'Yabin Hu'; llvm-commits at cs.uiuc.edu
Subject: Re: [Polly] Generating code for changed memory accesses

On 28/07/2014 19:11, Johannes Doerfert wrote:
> Hey,

Hey Johannes,

I am not sure I fully understand what you are explaining.

(I already replied to your previous patch, but I think it will be easier if we remove most of the in-flight changes here)

> The last version of the patch still has some flaws. One of which is caused by tiling/pre-vectorization.

The tiling/pre-vectorization is does not modify access functions, no? So this is only a concern because you enabled it 'by default'??

> Once the optimizer changes the number of dimensions, the access relation does not match the schedule anymore.

The number of dimensions of what? To my understanding the optimizer only changes the schedule. As the access relation does not reference the schedule, I don't see how there can be a mismatch?

> Fixing this is "easy" as we only need to apply the scattering of the schedule before we eliminate constant dimensions.
> However, we still have a problem if the "AST-codegen" will eliminate 
> dimensions And this iteration is not fixed in our access relation after applying the schedule (e.g. when we prevectorize a loop with 3 iterations).
> We somehow need to perform the same "transformation" as the AST-codegen to get an access relation which matches our actual schedule.
> Any thoughts on how to do that?

Now I am lost.

Do you have a test case?

Cheers,
Tobias







More information about the llvm-commits mailing list