[LLVMdev] Proposal for Poison Semantics

Sanjoy Das sanjoy at playingwithpointers.com
Wed Feb 4 18:29:28 PST 2015


> 'fadd nnan' claims that it is allowed to assume that its operands can't be
> NaN and that those which value depend on the value will not get NaN.  I
> believe this would let 'fcmp' assume that it only needs to look at the
> result of '%add':
> define i1 @f(i1 %a.is_nan, float %a, float %b) {
>   %add = fadd nnan float %a, %b
>   %cmp = fcmp ord float 0., %add
>   ret i1 %cmp
> }

The LangRef says: " Allow optimizations to assume the arguments and
result are not NaN. *Such optimizations are required to retain defined
behavior over NaNs, but the value of the result is undefined.*"

I'd interpret this as: "since %b is NaN, %add is undef".  I don't
think we can interpret the langref as allowing non-local reasoning
using nnan, since "fadd nnan NaN, foo" is explicitly not UB.  I guess
difficult part is deciding is what is meant by "result" here.

If we allowed nonlocal reasoning like this, we'd run into trouble with
hoisting 'fadd nnan's (I don't know if we do that now, so
sizeof(salt_grain)++) -- since we'd be changing the region in which
such non-local reasoning is valid.

-- Sanjoy

>


>
>>
>> Having said that I won't be surprised if fast-math flags suffer from
>> issues similar to poison -- "Allow algebraically equivalent
>> transformations that may dramatically change results in floating
>> point" sounds somewhat vague to me.
>>
>> -- Sanjoy
>>
>> >   ret i1 %cmp
>> > }
>> >
>> > Now we will have:
>> > %add = float undef
>> > %cmp = i1 undef
>> >
>> >
>> >>
>> >>
>> >>
>> >> John
>> >
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>
>



More information about the llvm-dev mailing list