[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:32 PM Sanjay Patel <spatel at rotateright.com> wrote:
>
>
>
>
> On Tue, Feb 25, 2020 at 10:13 AM Roman Lebedev <lebedev.ri at gmail.com> wrote:
>>
>> 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.
>
>
> Ah, I was missing that chain of transforms: undef -> nan (but we have "nnan"!) -> poison -> undef.
> It means that we can relax any FP undef folding to undef with -ffinite-math-only (or the larger -ffast-math).
> Not sure if that's going to conflict with any existing transforms, but it's probably worth adding to help vector code.
Ack