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

[Hal Finkel]

On Thu, 27 Sep 2012 16:46:03 +0530
Sameer Sahasrabuddhe <sameer.sahasrabuddhe at amd.com> wrote:

> On Thu, 27 Sep 2012 12:11:32 +0200
> Tobias Grosser <tobias at grosser.es> wrote:
> 
> > It seems we would need to mirror a lot of pattern matching from 
> > ScalarEvolution. Working directly on SCEVs could avoid this.
> 
> Currently, it's easy to confuse the delinearizer by computing two
> copies of the same value in the code, because the polynomials are
> neither uniq'ed nor canonicalized.

Technically, they are canonicalized (in the sense that they have a <
operation defined on them), but only over Values. As you point out,
using SCEVs instead might work much better; this should be easy to do.

Also, as has been pointed out, we don't want this pass to 'redo' logic
already contained in SE. It might be better to extract the polynomials
directly from the SCEVs of the index expressions. Further, it might be
better to use SCEVs directly instead of a separate polynomial class
(because SCEV's use a recursive polynomial decomposition, things like
counting terms in the multivariate sense become more complicated --
but it might be nevertheless worthwhile).

Thanks again,
Hal

> It is not desirable to assume that
> the input code will be optimized before being delinearized ...
> premature scalar optimizations might break Polly, for example.
> 
> The SCEV infrastructure seems ideal to resolve this. But I have not
> grokked SCEV's sufficiently yet to see the pros and cons of
> implementing the delinearizer on Value's v/s SCEVs.
>
> 
> Sameer.
> 



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