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

[Sebastian Pop]

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:

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

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