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

[Jeff Law <jeffreyalaw@gmail.com>]

On 8/29/2022 7:54 AM, 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.
I've always thought of singleton_p as having that purpose -- but in the 
integer world we never really had to think about multiple 
representations of the same value.  So it's entirely possible we're 
using singleton_p for multiple purposes.

Clearly if the representation has multiple representations for the same 
value, then we have to be more careful with propagation.  So we may need 
to separate the concept of "this has a value we can propagate" from 
"this has a constant value, but the value may have multiple 
represenatations".

I don't think it's worth trying to track the various NaN 
representations, but I do think it's worth tracking +-Inf and +-0.0.

jeff