[LLVMdev] confusion w.r.t. scalar evolution and nuw

[Sanjoy Das]

Hi,

> I missed this during review, possibly because it was a small part of a
> larger patch. I should have caught it because I'm well aware of
> exactly the same problem that occurs with IR canonicalization in
> Reassociate.

Thanks for the tip.  Now that I have a test case, I'll put up a fix
for review soon.  Do you think it makes sense to also change
ScalarEvolution::getMinuSCEV to throw away the no-wrap flags?  That is
another place where we make the (X - Y) == (X + (-Y)) judgment.

> To improve nsw/nuw awareness, we need a different approach. I think we
> should have some IR-level analysis of nsw/nuw to augment trip count
> computation.

That sounds interesting -- I don't have any well-formed ideas right
now, but I will try to come up with something.  One way to go about
this (that I've been thinking about in other contexts) is to annotate
scev expressions with arbitrary (not necessarily constant) ranges.
Since poison is UB only if it is used, we will have to have something
like getSCEVAtScope that gives us an "range-annotate SCEV" that is
valid at a given scope (i.e. given that we are about to execute an
instruction, what is the allowable range for a scev).  In this scheme,
a getSCEVAtScope(value = x, scope = (icmp (add nuw x, y) foo)) gives
us an scev for x annotated with the range [0, uint_max -
getSCEVAtScope(y, (icmp (add nuw x, y) foo))).  The nice thing is that
once we can represent general range information in the SCEV framework,
we can use it for things other than proving away overflow.

-- Sanjoy