[polly] r255922 - Fix delinearization of fortran arrays

Johannes Doerfert via llvm-commits llvm-commits at lists.llvm.org
Sun Dec 20 15:25:30 PST 2015


On 12/17, Roman Gareev via llvm-commits wrote:
> Author: romangareev
> Date: Thu Dec 17 14:37:17 2015
> New Revision: 255922
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=255922&view=rev
> Log:
> Fix delinearization of fortran arrays
> 
> The patch fixes Bug 25759 produced by inappropriate handling of unsigned
> maximum SCEV expressions by SCEVRemoveMax. Without a fix, we get an infinite
> loop and a segmentation fault, if we try to process, for example,
> '((-1 + (-1 * %b1)) umax {(-1 + (-1 * %yStart)),+,-1}<%.preheader>)'.
I get this part, the visitUMaxExpr was plain wrong.

> It also fixes a potential issue related to signed maximum SCEV expressions.
But I am confused by this part. Why do we check for two elements of the
SMax now? I know that delinearization is black magic combined with good
patterns but this seems to make things even more restrictive than they
were. I do not know why we do not strip __all__ 0's from the SMax if
that is what this piece of code is for and if it is sound:

assert(Expr.getNumOperands() > 1);

SmallVector<...> SMaxTerms;
for (Operand : Expr)
  if (!Operand.isZero())
    SMaxTerms.push(Operand)

NewExpr = getSMAx(SMaxTerms);
if (Terms)
  Terms.push_back(NewExpr)
return NewExpr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151221/36a27326/attachment.sig>


More information about the llvm-commits mailing list