Re: [PATCH] Add support for floating point endpoints to frange.

[Aldy Hernandez <aldyh@redhat.com>]

On Mon, Aug 29, 2022 at 4:08 PM Toon Moene <toon@moene.org> wrote:
>
> On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:
>
> > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
>
> >> For convenience, singleton_p() returns false for a NAN.  IMO, it makes
> >> the implementation cleaner, but I'm not wed to the idea if someone
> >> objects.
> >
> > If singleton_p() is used to decide whether one can just replace a variable
> > with singleton range with a constant, then certainly.
> > If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and
> > NaNs have lots of different representations (the sign bit is ignored
> > except for stuff like copysign/signbit, there are qNaNs and sNaNs and
> > except for the single case how Inf is represented, all other values of the
> > mantissa mean different representations of NaN).  So, unless we track which
> > exact form of NaN can appear, NaN or any [x, x] range with NaN property
> > set can't be a singleton.  There could be programs that propagate something
> > important in NaN mantissa and would be upset if frange kills that.
> > Of course, one needs to take into account that when a FPU creates NaN, it
> > will create the canonical qNaN.
> >
> >       Jakub
> >
>
> But the NaNs are irrelevant with -ffinite-math-only, as are the various
> Infs (I do not know offhand which MODE_ that is) ...

But even with -ffinite-math-only, is there any benefit to propagating
a known NAN?  For example:

if (__builtin_isnan (x)) {
  use(x);
}

or perhaps:
if (x != x) {
  use(x);
}

Should we propagate NAN into the use of x?

For that matter, AFAICT we don't even generate the unordered
comparisons needed to distinguish a NAN for -ffinite-math-only.

void foo(float f)
{
  if (__builtin_isnan (f))
    bark();
}

$ cat a.c.*original
;; Function foo (null)
;; enabled by -tree-original

{
  if (0)
    {
      bark ();
    }
}

Cheers.
Aldy