[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #11)
> _1 shoud be [-Inf, nextafter (0.0, -Inf)], not [-Inf, -0.0]

Well, that is a consequence of the decision to always flush denormals to zero
in
frange::flush_denormals_to_zero, because some CPUs do it always and others do
it when asked for (e.g. x86 if linked with -ffast-math).
Unless we revert that decision and flush denormals to zero only selectively
(say on alpha in non-ieee mode (the default), or if fast math (which exact
suboption?) etc.

(In reply to Aldy Hernandez from comment #10)
> BTW, I don't think it helps at all here, but casting from l_10 to a float,
> we know _1 can't be either -0.0 or +-INF or +-NAN.  We could add a range-op
> entry for NOP_EXPR / CONVERT_EXPR to expose this fact.  Well, at the very
> least that it can't be a NAN...in the current representation for frange's.

We definitely should add range-ops for conversions from integral to floating
point and from floating to integral and their reverses.  But until we have more
than one range, if the integral value is VARYING, for 32-bit signed int the
range would be
[-0x1.p+31, 0x1.p+31] so nothing specific around zero.  With 3+ ranges we could
make it
[-0x1.p+31, -1.][0., 0.][1., 0x1.p+31] if we think normal values around zero
are important special cases.
Not sure how that would help in this case.

The reduced testcase is invalid because it uses uninitialized l.