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

[Tobias Grosser]

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?

Cheers
Tobi