[llvm] r271151 - [SCEV] Don't always add no-wrap flags to post-inc add recs

Sanjoy Das via llvm-commits llvm-commits at lists.llvm.org
Mon May 30 13:38:48 PDT 2016


Hi Johannes,

On Mon, May 30, 2016 at 3:41 AM, Johannes Doerfert
<doerfert at cs.uni-saarland.de> wrote:
> Hey Sanjoy,
>
> I looked at the example in your commit message and I am not sure why/how
> our test case is affected. Does your patch really only change post-inc
> add recurrences? I ask because I do see the same output when I change
> the test case (e.g., move computation around). Maybe I misinterpret
> "post-inc add recurrence" because in the version below I would have
> though that there is no "post-inc add recurrence", even though I still
> get:

So there may be a terminology issue here.  By post-inc add recurrence,
I mean the incremented version of an add recurrence

>
>  %indvars.iv = phi i64 [ %indvars.iv.next, %bb4 ], [ 0, %bb ]
>    -->  {0,+,1}<nuw><nsw><%bb2>                                [EXPECTED]

^ this is the add recurrence

>  %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
>    -->  {1,+,1}<nuw><%bb2>                                  [NSW MISSING]

^ this is the post-inc version of the previous add recurrence.  It is
also an add recurrence in its own right, but relative to {0,+,1}, it
is post-inc.


The SCEV change in question fixes an issue where SCEV would transfer
the no-wrap flags of an add recurrence to its post-inc variant
unconditionally (and incorrectly).

Now in your example the {1,+,1} add recurrence _is_ nsw (and the fact
that nsw is missing is a weakness in
ScalarEvolution::isSCEVExprNeverPoison).  We should eventually address
that root cause, but if we canonicalize the loop via -loop-rotate,
SCEV is able to prove nsw; and D20778 does just that.  Alternately, we
could keep around the XFAIL till the weakness in
ScalarEvolution::isSCEVExprNeverPoison is addressed, but generally it
is not that useful to make optimization passes work better over
non-canonical IR when we can just be better at canonicalizing the IR
itself.

-- Sanjoy


More information about the llvm-commits mailing list