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

[Aldy Hernandez <aldyh@redhat.com>]

On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek <jakub@redhat.com> 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

Ok that was more or less what I was thinking.  And no, we don't keep
track of the type of NANs.

How does this look?

bool
frange::singleton_p (tree *result) const
{
  if (m_kind == VR_RANGE && real_identical (&m_min, &m_max))
    {
      // If we're honoring signed zeros, fail because we don't know
      // which zero we have.  This avoids propagating the wrong zero.
      if (HONOR_SIGNED_ZEROS (m_type) && zero_p ())
    return false;

      // Return false for any singleton that may be a NAN.
      if (!get_nan ().no_p ())
    return false;

      if (result)
    *result = build_real (m_type, m_min);
      return true;
    }
  return false;
}

Thanks.
Aldy

> 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
>