[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