[llvm] a253a2a - [SDAG] fold fsub -0.0, undef to undef rather than NaN

[Roman Lebedev via llvm-commits]

On Tue, Feb 25, 2020 at 6:04 PM Sanjay Patel <spatel at rotateright.com> wrote:
>
>
>
> On Mon, Feb 24, 2020 at 10:44 AM Nuno Lopes <nuno.lopes at ist.utl.pt> wrote:
>>
>> > ----------------------------------------
>> > Name: t1
>> >  %r = fsub half 4.000000, undef
>> >  ret %r
>> > =>
>> >  ret undef
>> >  %r = fsub half 4.000000, undef
>> >
>> > ERROR: Value mismatch
>> >
>> > Example:
>> > half %r = NaN   [based on undef value]
>> > Source value: NaN
>> > Target value: #x8500 (-0.000076293945?)
>> >
>> >
>> > @Nuno: is this a bug in alive?
>>
>> What Alive is trying to say is that there's no value x that makes "4.0 - x" yield the number 0x8500.
>> I think Alive is correct here. FP operations usually can't produce the whole range of bit-patterns.
>
>
> That was my conclusion from the review discussion and what I was hinting at in the commit message.
>
> So this Alive example that includes "nnan" is incorrect IIUC:
>
> %r = fsub nnan half 4.000000, undef
>  ret %r
> =>
>  ret undef
>
> Optimization is correct!
>
> ...because the "nnan" does not change the fact that we can't produce the entire range of FP bit-patterns.
That wouldn't be my personal take on this, based on how i'd understand
`nnan` from
https://llvm.org/docs/LangRef.html#fast-math-flags
  No NaNs - Allow optimizations to assume the arguments and result are not NaN.
  If an argument is a nan, or the result would be a nan, it produces a
poison value instead.

I.e. roughly i read this as: undef can be defined to a NaN constant,
but then since 'nnan' is specified, the result is poison which we opt
to relax into 'undef'.
But i may be missing some fineprint.

Roman