De-pessimize ScalarEvolution's handling of nsw/nuw?

[Sanjoy Das]

Re-reading what I just sent, a clarification: I think "another
non-control-equivalent instruction *with* nsw/nuw can be mapped to the
same expression" is irrelevant; and the rationale really is about
scev's not remembering control dependence information.

On Mon, Dec 15, 2014 at 9:25 PM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
>> The comments in the source code say that ScalarEvolution does not
>> apply an instruction's nsw/nuw flags to the corresponding SCEV
>> expression because another non-control-equivalent instruction without
>> nsw/nuw can be mapped to the same expression.
>
> I think the problem is that another non-control-equivalent instruction
> *with* nsw/nuw can be mapped to the same expression and you may end up
> introducing nsw / nuw operations in paths that didn't have any to
> begin with.  IOW since you "forget" the control dependence when
> translating a value to a scev, you cannot rematerialize or reason
> about the scev in arbitrary points in your program if the scev has
> potential to introduce UB.
>
> Having said that, I don't fully understand poison and LLVM's
> overflowing semantics; and it may be that it is possible to justify
> mapping nsw binary ops to nsw scevs under certain conditions or
> maybe even always.  But it is not something that is obviously true.
>
> -- Sanjoy