split delinearization pass in 3 steps

[Sebastian Pop]

Patch attached.

On Thu, May 1, 2014 at 5:01 PM, Sebastian Pop <spop at codeaurora.org> wrote:
> Hi,
>
> here is a rewrite of the delinearization analysis to address a few problems that
> arise when we started integrating this analysis in Polly.  In particular, this
> rewrite splits the delinearization pass in 3 steps to compute the dimensions of
> the array in a unique way (in the past we used to compute the array dimensions
> in a different way for every memory access function, and so the delinearization
> would fail if the detected shapes were different.)
>
> To compute the dimensions of the array in a unique way, we split the
> delinearization analysis in three steps:
>
> - find parametric terms in all memory access functions
> - compute the array dimensions from the set of terms
> - compute the delinearized access functions for each dimension
>
> The first step is executed on all the memory access functions such that we
> gather all the patterns in which an array is accessed. The second step reduces
> all this information in a unique description of the sizes of the array. The
> third step is delinearizing each memory access function following the common
> description of the shape of the array computed in step 2.
>
> This rewrite of the delinearization pass also solves a problem we had with the
> previous implementation: because the previous algorithm was by induction on the
> structure of the SCEV, it would not correctly recognize the shape of the array
> when the memory access was not following the nesting of the loops: for example,
> see polly/test/ScopInfo/multidim_only_ivs_3d_reverse.ll
>
> ; void foo(long n, long m, long o, double A[n][m][o]) {
> ;
> ;   for (long i = 0; i < n; i++)
> ;     for (long j = 0; j < m; j++)
> ;       for (long k = 0; k < o; k++)
> ;         A[i][k][j] = 1.0;
>
> Starting with this patch we no longer delinearize access functions that do not
> contain parameters, for example in test/Analysis/DependenceAnalysis/GCD.ll
>
> ;;  for (long int i = 0; i < 100; i++)
> ;;    for (long int j = 0; j < 100; j++) {
> ;;      A[2*i - 4*j] = i;
> ;;      *B++ = A[6*i + 8*j];
>
> these accesses will not be delinearized as the upper bound of the loops are
> constants, and their access functions do not contain SCEVUnknown parameters.
>
> Tobi has helped review the previous algorithm and he pointed out a direction to
> fix the problems we have seen with the delinearization. This has happenend in
> the last two polly phone calls:
> https://docs.google.com/document/d/14d3ehkH2MsvBdqsEOSYjysH0Ztyzb75Lp843hnxh2IA/edit?usp=sharing
> https://docs.google.com/document/d/1IZewI8Up0iEkCNIPr6gVtwJxF7RV6KmXkdwOBM_Q5Cs/edit?usp=sharing
>
> Ok to commit?
>
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-split-delinearization-pass-in-3-steps.patch
Type: text/x-patch
Size: 58413 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140501/806a22b9/attachment.bin>