[PATCH] Fix bug 22641

Sanjoy Das sanjoy at playingwithpointers.com
Mon Feb 23 13:36:42 PST 2015


> I asked that question because I thought the test case was failed when postinc recurrence was marked NUW but the preinc recurrence was not. Now I can see that *any* recurrence on this loop will be NUW. That may make sense in theory, but could cause some real practical problems within SCEV. It looks like you already caught one in SCEVExpander.

(fwiw, I had this exact same discussion with Philip a few hours ago).

This is very similar to the discussion we had w.r.t. the <nw> flag.
Given that the algebraic condition that decides if a recurrence is
<nw> is satisfied by BECount == 0, all recurrences in a loop that
never takes a backedge are trivially <nw>.  The same is true for <nuw>
and <nsw>, as far as I can tell.

> My main takeaway from this is that the recurrence's wrapping flags are a property of the pre-incremented value within the loop. So that IV increment may actually wrap on the last iteration. I've been making the assumption that the post-incremented value would be tested on the last iteration and was guaranteed not to wrap. That's slightly shady because the value might not actually be used (and isn't even "consumed" by a phi), but it seemed to be the expectation based on other code I'd seen.

I agree; that is my mental model also -- the "next" value of a SCEV is
computed as loop takes the backedge, and that is when all the nuw,
nsw, nw flags apply.  In this sense, add recs have a very structured
form of control dependence.

Unless we allow this, we won't be able to mark add recs as nuw/nsw/nw
for loops with variable trip count.  I also don't think this is very
problematic (though a little subtle, I'll have to admit) -- we just
have be very explicit that the no-wrap flags on a add rec are valid
for that scev only; and do not apply to the pre-inc or post-inc
version of that scev.  So sext({S,+,X}<nsw>) is still {sext S,+,sext
X} and {S,+,1}<nsw> is still always sge 1.  {S,+,X}+X == {S+X,+,X} is
a totally different scev and the no-wrap behavior of the former does
not apply to the latter.

Does this sound sensible?

I'll check in a change that adds some more elaborate comments
detailing whatever we decide once we've reached a fixed point.

-- Sanjoy

>
> Do you have a better explanation?
>
>
> http://reviews.llvm.org/D7808
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>




More information about the llvm-commits mailing list