[PATCH] Fix bug 22641

[Andrew Trick]

> On Feb 23, 2015, at 1:36 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
>> 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.

Yes.

> 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}

Good. So that’s true for all users of a value that evaluates to the <nsw> SCEV regardless of whether they are conditionally executed outside the loop. More generally, once that back-edge is taken, integer overflow induces undefined behavior. i.e. it doesn’t matter whether the IV was actually tested on the backedge or even used on any path that the program takes. That way we can use the presence of the SCEV flags on a recurrence to prove things about other recurrences. Right?

> and {S,+,1}<nsw> is still always sge 1.

I’m missing something here. We *don’t* know that ({S,+,1}<nsw> - {S-1,+,1}<nsw>) 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.

Yes.  But you could use NSW on one of the recurrences to help prove the other. e.g. after proving that the first increment doesn’t overflow.

> 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.

Fantastic.

- Andy

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