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

[Hal Finkel]

On Fri, 28 Sep 2012 19:34:01 -0700
Andrew Trick <atrick at apple.com> wrote:

> 
> On Sep 27, 2012, at 3:11 AM, 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.
> > 
> > @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?
> 
> If we ignore SCEVExpander and only consider SCEV-the-analysis, then
> we have a pretty robust system. There are a few issues:
> - LCSSA form artificially limits analysis.
> - SCEV inherently cannot preserve nsw/nuw flags. When it attempts to
> do it, the results can depend on the query order.
> - Expressions with sext/zext/trunc do not have a canonical form.
> - SCEV queries can take time exponential to the expression depth
> (mainly a problem because of sext/zext/trunc).
> 
> SCEV should be just fine within a single loop nest with simple
> induction variable expressions.
> 
> It seems like SCEV has already done the hard work of factoring the
> polynomial according to the loop nesting and finding the interesting
> coefficients. But I don't understand Hal's algorithm well enough yet
> to claim that it's trivially adapted to chains of recurrences.

Does SCEV canonicalize the ordering of the the recurrences? What I mean
is that if I have a value which is a function of multiple loop
induction variables I'll get a recurrence which will have coefficients
that are a recurrence which will have coefficients that are a
recurrence, etc. As far as I can tell, these recurrences are just
univariate polynomials. Can I depend on these recurrences being nested
with loop depth?

 -Hal

> 
> -Andy



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