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

[Jeff Law <jeffreyalaw@gmail.com>]

On 8/29/2022 8:15 AM, Aldy Hernandez via Gcc-patches wrote:
> On Mon, Aug 29, 2022 at 4:08 PM Toon Moene <toon@moene.org> wrote:
>> On 8/29/22 15:54, 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.
>>>
>>>        Jakub
>>>
>> But the NaNs are irrelevant with -ffinite-math-only, as are the various
>> Infs (I do not know offhand which MODE_ that is) ...
> But even with -ffinite-math-only, is there any benefit to propagating
> a known NAN?  For example:
In theory, yes, but I don't know if it's worth the headache in practice 
for NaNs, particularly given they can have many representations.

Jeff