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

[Sanjay Patel via llvm-commits]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200225/f8c3e687/attachment.html>