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

[Andrew Trick]

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.

-Andy