[LLVMdev] ScalarEvolution::createNodeForPHI

[Michele Scandale]

On 10/03/2013 01:22 AM, Andrew Trick wrote:
> 
> I’m not sure how to make sense of an NUW flag coming from a sub.
> 
> NSW is just a misnomer for signed overflow. SCEV canonicalizes sub a,b to add a, (-b). Unfortunately, signed overflow is not the same thing for sub and add...
> 
> sub nsw %a, %b != add nsw %a, (-1 * %b)
> 
> sub nsw i32, -1, INT_MIN is true.
> 
> add nsw i32, -1, (-1 * INT_MIN) is false.
> 
> NSW flags just aren’t an effective way to tell SCEV about overflow. Ideally we could reason more generally about the loop’s undefined behavior. For example, I’d like to query the range of values that a variable can hold before the loop hits undefined behavior. I don’t know how to implement something like this yet. Ideas are welcome.
> 
> Reading this code again, even the addition case looks too aggressive to me.
> See:
> llvm.org/PR17452 - SCEV createNodeForPHI is too optimistic about NSW.
> 

If the behavior is different between 'add nsw' and 'sub nsw' then the SCEV
canonicalization of 'sub' leads to incorrect results.

In your example both result should be the same but the 'add' produces a poison
value. Is this what we really want?

The case of an expression with mixed operator ('add' with and without nsw) flag
would require an explicit representation of the two operator making more complex
reassociation, simplification and reordering of the expression operands.

Your proposed workaround of checking that the BEValue is an operation between
the PHINode Value and a loop invariant would be fine but it's still a workaround.

-Michele