[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