[llvm-dev] Loop Opt WG - concerning delinearization.

Gary Elsesser via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 3 06:37:18 PDT 2019


Note the llvm/lib/Analysis/Delinearization.cpp   recommends

SCEVAddRecExpr::delinearize().

See also llvm/lib/Analysis/DependenceAnalysis.cpp w/r the GEP operator.


Also note this 2015 paper:

  *   On recovering multi-dimensional arrays in Polly
Tobias Grosser, Sebastian Pop, J. Ramanujam, P. Sadayappan
Impact2015 at HiPEAC, Amsterdam, The Netherlands
Slides & Paper: Impact 2015<http://impact.gforge.inria.fr/impact2015/>

               http://impact.gforge.inria.fr/impact2015/


Delinearization is useful, particularly when the code has been hand linearized,

as is often the case for C/C++.  Nonetheless, information may be lost by lowering

multidimenional array references early.  Consider:


   float A[n1][n2], B[n2];

   for (i = 0; i < ni; ++i)

      for (j = 0; j < nj; ++j)

          A[ix[i]][j] += B[j];


Even in C, the compiler may assume 0 <= j < n2.

In Fortran this is beyond dispute.  But after linearization,

even with delinearization, the fact that nj <= n2 is not

known at compile time.  If the subscripts to A where

interchange the situation is even worse, as 0 <= ix[i] < n2

is expensive to verify.


So delinearization provide a benefit w/r hand linearized subscripts,

while analysis of actual multidimensional references is best

done prior to linearization - before information is lost.


Gary Elsesser

  Cray, Inc.

  Bloomington, MN

  gwe at cray.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190703/d43e691c/attachment.html>


More information about the llvm-dev mailing list