[llvm-dev] RFC: Killing undef and spreading poison

[Peter Lawrence via llvm-dev]

John,
         I’m not saying the transformation is illegal with respect to ’t’,
I am saying the transformation is illegal with respect to ‘prod’

I wil use Sanjoy’s example
	‘x' = (1 << 16),   'y' = (1 << 16),   and ‘condition' precludes those values

Before the transformation ‘nsw’ says the the multiply will not overflow,

But after the transformation the multiply *will* overflow, and ‘nsw’ is no longer valid.

The point is not that you can’t hoist the multiply, but rather that the ‘nsw’ attribute no longer applies after that hoisting.


I think the LLVM community in general has misunderstood and misused ‘nsw’, don’t you agree now ?


Peter Lawrence.



> On Jun 7, 2017, at 2:27 PM, John Regehr <regehr at cs.utah.edu> wrote:
> 
> Peter, it looks to me like you've misunderstood how nsw works.  You are saying that the transformation below is incorrect.  If it is incorrect, there needs to be a valuation of x and y (and also a choice of "..." and "condition") that causes the transformed code to call use(t) with a different t than the original code would have.  Please tell us those values.
> 
> John
> 
> 
>>   for (...) {
>>     if (condition){
>>       i32 prod = x *nsw y
>>       i64 prod.sext = sext prod to i64
>>       i64 t = K `udiv` (-1 + (sum.prod >> 32))
>>       use(t)
>>     }
>>   }
>> 
>> ==> (step 1) multiplication and sext can be speculated
>> 
>>   i32 prod = x *nsw y
>>   i64 prod.sext = sext prod to i64
>>   for (...) {
>>     if (condition){
>>       i64 t = K `udiv` (-1 + (prod.sext >> 32))
>>       use(t)
>>     }
>>   }