On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek <[email protected]> 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
>
