[llvm-dev] [SCEV] Inconsistent SCEV formation for zext

[Chawla, Pankaj via llvm-dev]

Hi Sanjoy,

SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case-
%conv5 = zext i32 %dec to i64

If we request a SCEV for the instruction, it returns-
(zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64)

This can be seen by invoking-
$ opt -analyze -scalar-evolution inconsistent-scev-zext.ll

But when computing the backedge taken count of the containing loop for.body7, it is able to push zext inside the AddRec and forms the following for the same instruction-
{(zext i32 {-1,+,1}<%for.body> to i64),+,-1}<nw><%for.body7>

This allows ScalarEvolution to compute a valid backedge taken count for the loop.

The 'simplification' is done by this piece of code inside getZeroExtendExpr()-

            // Cache knowledge of AR NW, which is propagated to this
            // AddRec.  Negative step causes unsigned wrap, but it
            // still can't self-wrap.
            const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNW);
            // Return the expression with the addrec on the outside.
            return getAddRecExpr(
                getExtendAddRecStart<SCEVZeroExtendExpr>(AR, Ty, this,
                                                         Depth + 1),
                getSignExtendExpr(Step, Ty, Depth + 1), L,
                AR->getNoWrapFlags());
          }

I believe it is wrong for ScalarEvolution to use a simplified SCEV for internal analysis and return a non-simplified SCEV to the client.

Thanks,
Pankaj


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/0fa8fc65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inconsistent-scev-zext.ll
Type: application/octet-stream
Size: 2421 bytes
Desc: inconsistent-scev-zext.ll
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/0fa8fc65/attachment.obj>