[Polly] Generating code for changed memory accesses

Tobias Grosser tobias at grosser.es
Thu Jul 31 15:01:11 PDT 2014


On 31/07/2014 23:41, Johannes Doerfert wrote:
> If I do 1) I will fail the tests, that's the reason I didn't split them.

That's exactly the point, we now need to reason about the test cases and
what kind of changes are involved. ;-)

If we split them we can make clear that the changes are minimal, such 
that this reasoning also becomes trivial.

To your problem: Why would they fail? I remember you mentioned something 
about a different context being expected by isl. What is the minimal set 
of changes necessary to move the tests to the IslCodegeneration? Just 
changes to the context fields in the .json files?

> I think 2) is a nice way to go, but I first need to move the privatization stuff to the IslAst level before I can use it the way you describe it.
> Till then I'd think this way is more general as it allows both use cases (early or late creation of the isl_ast_exprs).

As I said, I am fine to leave it in the IslCodeGeneration

> Ok, what's the final decision on how we proceed?

I would like to understand why splitting of the test case move is 
difficult. If it is non-trivial, then I did not understand the patch yet 
completely.

Cheers,
Tobias



More information about the llvm-commits mailing list