[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