[LLVMdev] nsw is still logically inconsistent

Dan Gohman gohman at apple.com
Wed Dec 14 16:09:56 PST 2011


On Dec 14, 2011, at 12:11 PM, Eli Friedman wrote:

> 2011/12/14 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>:
>>> We first perform a speculation transformation, hoisting all of the
>>> code above the %overflow_check branch:
>>> 
>>>   %t0 = add nsw i32 %a, %b
>>>   %t1 = sext i32 %t0 to i64
>>>   %t2 = ashr i64 %t1, 31
>>>   %t3 = add i64 %t2, 1
>>>   %t5 = icmp ult %t3, 2
>>>   %t6 = udiv i1 1, %t5
>>>   br i1 %overflow_check, label %no_overflow, label %end
>>> 
>>> no_overflow:
>>> 
>>> Was this valid?
>>> 
>>> If nsw overflow is immediate undefined behavior, this transformation
>>> would break the program, because the overflow is no longer guarded
>>> by %overflow_check. But a premise of this exercise is that we want
>>> to be able to speculate add nsw instructions. For now, let's assume
>>> that there's a way to define nsw which permits this, with some kind
>>> of deferred undefined behavior semantics.
>> 
>> Could we say that moving the udiv was invalid? It is a instruction
>> witch can cause undefined behavior and doing the move makes it exposed
>> to poison values in conditions it was not before.

We could, but it would preclude desirable optimizations.

> Note that this matches existing practice: IIRC, for a testcase like
> the given testcase, LICM will hoist everything except the div
> instruction.


LICM on ToT hoists the div. Even speculatively.

The other thing is that div is just one example. The problem could
also come up with an array load with an index could be safe to
speculate if the index is known to be bounded. isDereferenceablePointer
currently doesn't know how to do this, but it'll probably get
smarter some day.

Dan





More information about the llvm-dev mailing list