[Polly] Generating code for changed memory accesses

Tobias Grosser tobias at grosser.es
Mon Jul 28 10:26:45 PDT 2014


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