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

[Arnold Schwaighofer]

On Oct 11, 2013, at 9:27 AM, Sebastian Pop <spop at codeaurora.org> wrote:

> Hi Arnold and Tobi,
> 
> Tobias Grosser wrote:
>> On 10/10/2013 11:41 PM, Arnold Schwaighofer wrote:
>>> if (n < umax(i4)/4) {
>>>  // vectorized loop. perform math in scev with assumption that "{0,+,4}<%for.cond1.preheader> < umax(i4)/4?.
>>> } else
>>>  // scalar loop
>>> 
>>> I think, for all this to work we would need some framework on top of/within
>>> scev that enables us to ?work with SCEV under the assumption X?. This would
>>> be useful for other things (e.g. getting rid of z/sexts in scev expressions,
>>> etc http://llvm.org/bugs/show_bug.cgi?id=16358, which in term simplifies
>>> dependence testers based on scev).
> 
> Because SCEV analyzes the original code (before versioning), SCEV should report
> a conservative expression not assuming any extra constraints (as it does today.)
> 

Yes. Absolutely, that is why I was saying a framework on top of SE. (SE should stay modulo arithmetic safe)

> SCEV could collect the constraints under which it can compute a simpler
> expression. Then we could decide to add these constraints to our versioning
> decision and perform an "instantiation" of the SCEVs under these assumptions.
> 

Interesting, in such a framework - if I understand you correctly - whenever we simplify an expression we would have to try several assumptions: a harder problem?  In such a scenario, could we have several combinations of assumptions leading to different results with maybe different simplified expressions? Is there a canonical such simplified expression? Is that the useful one? (It seems to me that would be a constant/loop invariant combination, assume loop count = 0 or 1). How do you guide the search in that tree of assumptions to find the answer we care about?

Can you elaborate more how that would work?

- - -

Alternatively. 

The above concern is why I would feed a set of assumptions to said framework:

NewSCEV = simplifyingSCEVFramework(SE, {set of assumptions}, SCEV).


Now, finding this set of assumptions might be a dual problem to the one above, but I would hope that those assumptions can be gleaned from the shape of the IR.

for (i = 0, n)
 for (y = 0, m)
   a[i][y] = 

=> assume m such that we don’t overrun sizeof(a[0]).

for (i = 0, n)
  a[2 *i] = 

=> assume n < sizeof(intptr_t)/2

for (int i = 0, n)
  a[4*i]

=> assume n < intmax/4 // signed arithmetic


for (i = 0, n)
 for (y = 0, m)
   *(a+(i*dim1)+y) =

assume m < dim1.

(I have not looked at Hal’s patch - maybe he is already doing something like that?)

Would something like this be useful to the problem of multidimensional array index delinearization? Can we find such constraints from the IR (I give some simple examples above but I am sure there are more interesting non-trivial examples that you guys know/care about ;)?

Thanks,
Arnold

> If the analyzed code contains assumptions (asserts, conditions, loop bounds) and
> do not require versioning, SCEV should use all these assumptions.

> 
>> Yes, this seems the right approach. I remember HAL's pass provided
>> with the delinearization a set of conditions that had to hold for
>> this delinearization to be valid. In most cases we probably do not
>> observe wrapping so assuming it does not happen and adding run-time
>> checks in case it does seems to be the right approach.
> 
> Right.
> 
> Thanks for your feedback!
> Sebastian
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation