[LLVMdev] RFC: Proposal for Poison Semantics (original) (raw)

Philip Reames listmail at philipreames.com
Thu Jan 29 10:33:07 PST 2015

On 01/28/2015 11:29 PM, Sanjoy Das wrote:

I don't think your example is actually problematic. The original program before your transformation executed undefined behavior in the form of '%x = add nuw i32 %m, %n' with "%m = %n = 2^32-1 (a.k.a INTMAX)". If I I was trying to show why the rule "signed overflow is undefined behavior" is problematic w.r.t. hoisting arithmetic by repeating an argument David made in the first email on this thread. That particular example is not a counterexample to the RFC. Er, I really don't get your point here. This is a direct mapping of what the C++ spec says onto LLVM IR. Can you clarify what you mean? The RFC has issues with icmps, sexts and zexts; but they're distinct from the hoisting problem. Can you enumerate? Or give an example?

%x1 = add nuw i32 %m, %n %x = select i1 %cnd x1, 0 %y = zext i32 %x to i64 %s = lshr i64 %y, 32 %addr = gep %someglobal, %s store i32 42, i32* %addr

This is well defined as per the spec David sent out. %x is not poison. %x1 is, but that's fine. AFAICT, going by the RFC, %x is poison iff %x1 is poison and %cond is true. You're correct; I was sloppy in my wording. What I should have said was that %x is poison exactly when the original program would have executed undefined behaviour. If the original program was well defined (and thus %cnd is false), %x is not poison. That seems like exactly what we want.

Philip

More information about the llvm-dev mailing list