On Mon, Aug 29, 2022 at 04:08:58PM +0200, Aldy Hernandez wrote:
> On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek <ja...@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;
Perhaps if (HONOR_NANS (m_type) && !get_nan ().no_p ()) instead?
Or do you ensure the nan property is never set for -ffinite-math-only?
>
> if (result)
> *result = build_real (m_type, m_min);
> return true;
> }
> return false;
> }
Otherwise LGTM.
Jakub
