[llvm-commits] [PATCH] Multidimensional Array Index Delinearization Analysis

Hal Finkel hfinkel at anl.gov
Thu Sep 27 05:20:18 PDT 2012


On Thu, 27 Sep 2012 12:11:32 +0200
Tobias Grosser <tobias at grosser.es> wrote:

> On 09/27/2012 11:29 AM, Sameer Sahasrabuddhe wrote:
> >
> > Hi Hal,
> >
> > I tried the version from Delinearization-20120926.patch on a Fortran
> > loopnest, with -O3 before invoking delinearization. See attached
> > file "m.pre.ll".
> >
> > The delinearizer misses out on the negation expression implemented
> > as an XOR (the value "%not"):
> >
> >      ~n = -n - 1
> >
> > As a result, the "n" above is not available as a possible term in a
> > GCD. It worked when I manually substituted that negation with its
> > expansion. I am not sure if this should be handled as an additional
> > method "addPolysForXor()", or the IR itself should be modified as a
> > precursor to delinearization. This expansion is similar to what
> > happens in ScalarEvolution::getNotSCEV().
> 
> It seems we would need to mirror a lot of pattern matching from 
> ScalarEvolution. Working directly on SCEVs could avoid this.
> 
> Another remark comping from a similar angle. The current analysis is
> not on demand, but always iterates over all instructions. I have the
> feeling within LLVM, people try to perform analysis on demand (e.g.
> Prestons Dependency Analysis, but also ScalarEvolution). Working
> directly on SCEVs would make it easy to do an on-demand analysis that
> is only called for the scevs used by memory access instructions.

I agree; this should be tried. I already had the polynomial extraction
code written, which is why I used it; it was not really a design
decision. I think that I now understand the requirements well enough to
try extracting things from the SCEVs directly.

 -Hal

> 
> @Andrew: I remember you mentioned that ScalarEvolution has some
> design problems. Could you elaborate on them and if they would cause
> issues in this context?
> 
> Cheers
> Tobi
> 



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-commits mailing list