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
