On Mon, Aug 29, 2022 at 4:17 PM Jakub Jelinek <ja...@redhat.com> wrote:
>
> 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?
See followup with Tom downthread.
Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
for -ffinite-math-only? I suppose it's cleaner with HONOR_NANS....
Aldy
