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: if (__builtin_isnan (x)) { use(x); } or perhaps: if (x != x) { use(x); } Should we propagate NAN into the use of x? For that matter, AFAICT we don't even generate the unordered comparisons needed to distinguish a NAN for -ffinite-math-only. void foo(float f) { if (__builtin_isnan (f)) bark(); } $ cat a.c.*original ;; Function foo (null) ;; enabled by -tree-original { if (0) { bark (); } } Cheers. Aldy