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

[Andrew Trick]

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

> Hi all,
> 
> I was in the mid of updating and sending out Hal's patch for review. When I
> tried to summarize all the review comments from this long thread, I realized
> that Andy has sent a nice description of how to implement the delinearization on
> top of SCEV:
> 
> Andrew Trick wrote:
>> The SCEV way to handle this would be to call getUDiv to divide the
>> recurrence's start by the recurrence's step. Any remainder is added to the
>> current dimension's index. The quotient is itself a recurrence, so the process
>> continues for each dimension.
> 
> This seems to work pretty nicely when I was running it by hand on all the tests
> from Hal's patch.  The implementation is also pretty elegant because of the
> recurrence on the structure of SCEVs.
> 
> Now there is a missing piece:
> 
>> The problem that I see is that ScalarEvolution::getUDivExpr doesn't implement
>> any normalization except for division by constants.
>> 
> 
> It looks to me that getUDivExpr does not provide enough functionality to drive
> the delinearization (even in the case of division by constants.) Here is what
> happens when trying to delinearize this SCEV:
> {{{0,+,(8 * %m * %o)}<%for.cond1.preheader>,+,(8 * %o)}<%for.cond4.preheader>,+,8}<%for.body6>
> 
> Start: {{0,+,(8 * %m * %o)}<%for.cond1.preheader>,+,(8 * %o)}<%for.cond4.preheader>
> Step: 8
> SE.getUDivExpr(Start, Step) returns:
> ({{0,+,(8 * %m * %o)}<%for.cond1.preheader>,+,(8 * %o)}<%for.cond4.preheader> /u 8)
> 
> Should I try to improve SCEV's way to fold UDiv expressions? Or should I try to
> fold UDiv Value expressions:

As Arnold correctly pointed out, getUDivExpr cannot legally do this for you. However, maybe you could implement a separate helper that scales a recurrence ignoring overflow. You know the final result will be rescaled so you won't lose any overflow behavior. Generating a UDiv is a bit silly anyway.

>> Still, it would be worth attempting to solve this problem without a separate
>> polynomial package. I could imagine special-casing the solution for the kind
>> of nested recurrences that we expect to see. It might also make sense to do
>> the division "implicitly" without attempting to create a SCEVUDiv
>> expression. I think you're only dealing with linear expressions of a fairly
>> regular form. SCEV's ability to canonicalize and unqiue expressions certainly
>> helps. I can't say for sure whether this will lead to a simpler
>> implementation, but I hope you consider it.
> 
> Probably an easier way would be to implement an ad-hoc pattern matching to
> figure out whether Step occurs in each operand of Start, and that would also
> give me a simple way to compute the remainder in case it does not divide one of
> the operands.
> 
> Let me know what would be the best to implement.

Sure. Sameer pointed out in this thread that the general problem is one of finding a GCD of the start and step. But in this situation there's nothing wrong with pattern matching common cases.

-Andy

> Thanks,
> Sebastian
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation