[Polly] Generating code for changed memory accesses

Johannes Doerfert jdoerfert at codeaurora.org
Thu Jul 31 15:42:55 PDT 2014


>> 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?
There are two problems, but if you just want to keep these tests you just need to address the first one:
  1) Change the context from { [] } to { : }
  2) As soon as scev codegen is turned on and we have new access functions we crash.
 
--

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: Thursday, July 31, 2014 3:01 PM
To: Johannes Doerfert
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [Polly] Generating code for changed memory accesses

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