On 8/29/2022 8:15 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 4:08 PM Toon Moene <t...@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
