[Polly] Generating code for changed memory accesses

[Johannes Doerfert]

Hey Yabin,

good to hear that the patches work for you.

Did you only apply these patches or "review" them?

Best reagards,
  Johannes


On 08/02, Yabin Hu wrote:
> 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
> >
> >

-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.26

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140802/a50b48ce/attachment.sig>