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

[Tobias Grosser]

On 09/29/2012 04:34 AM, Andrew Trick 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?

Hi Andrew,

> 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.

What is a single loop nest? Or better, what would be more complex than a 
single loop nest?

Is this is a single loop nest?

| for i
|   for j

This as well?

| for i
|  for j
|
| for k

Or just if it is surrounded by a common loop? Do you have an example for 
something that is not a single loop nest?

I am interested, as we use SCEV to derive loop bounds and array 
subscripts in Polly. We basically base our high level loop 
transformations on SCEV. Until now, I did not see any problems. This
may be due to the constraints we put on the kind of loop nests we 
optimize, but also because we have been lucky so far. Do you think it 
was a bad decision to base Polly on SCEV?

I was actually even thinking of "improving" Polly by using SCEVExpander
extensively. When recreating a new loop structure we move basic blocks 
from the old loop nest to a new one. For now, we use the old indvars 
pass to rewrite all loops to single induction variable loops. This 
allows us to rewrite the blocks by replacing the explicitly available 
old induction variables with the ones of the new loop nest. To remove 
the need for the old indvars pass, I was thinking of rewriting based on 
SCEVs. I would basically take the SCEV of a value that I want to rewrite
and I would replace all AddRec expressions that reference an old iv, 
with a reference to the newly calculated ivs. I would then use the 
SCEVExpander to code generate these 'updated' SCEVs. Does this sound 
like a good idea or what kind of problems would I face with this approach?

Thanks
Tobi