[Polly] Generating code for changed memory accesses

Yabin Hu yabin.hwu at gmail.com
Sat Aug 2 07:25:26 PDT 2014


Hi Johannes,

I have rebased my GSoC project totally on top of these three patches and
the polly trunk, it works well at the moment. Very nice patches!

As Tobias has explained, I compute an entirely new ast node and use the
islcodegeneration to translate it into LLVM IR. That's why I always have
the context from which I can get the isl_ast_build.

Thanks,
Yabin


2014-08-02 1:27 GMT+02:00 Johannes Doerfert <jdoerfert at codeaurora.org>:

> Please see the attached patches
>
> --
>
> 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:48 PM
> To: Johannes Doerfert
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [Polly] Generating code for changed memory accesses
>
> On 01/08/2014 00:42, Johannes Doerfert wrote:
> >>> 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.
>
> The second already exists in the current code, so it is not really a
> regression (You can use an explicitly disable scev code generation if this
> helps to keep your internal tests running).
>
> The first one seems easy to do. Could you move the tests and mention in
> the commit message that this is the only change that has been applied to
> these files.
>
> The remaining patch should then not need to change these files, no? If
> this is the case, you can mention in the commit messages that the change is
> tested by existing test cases (maybe point to them).
>
> Cheers,
> Tobias
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140802/6f0af6ce/attachment.html>


More information about the llvm-commits mailing list