On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek <ja...@redhat.com> wrote:
On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
It seems to me we can do this optimization regardless, but then treat
positive and negative zero the same throughout the frange class.
Particularly, in frange::singleton_p(). We should never return TRUE
for any version of 0.0. This will keep VRP from propagating an
incorrect 0.0, since all VRP does is propagate when a range is
provably a singleton. Also, frange::zero_p() shall return true for
any version of 0.0.
Well, I think for HONOR_SIGNED_ZEROS it would be nice if frange was able to
differentiate between 0.0 and -0.0.
One reason is e.g. to be able to optimize copysign/signbit - if we can
prove that the sign bit on some value will be always cleared or always set,
we can fold those.
On the other side, with -fno-signed-zeros it is invalid to use
copysign/signbit on values that could be zero (well, nothing guarantees
whether the sign bit is set or clear), so for MODE_HAS_SIGNED_ZEROS &&
!HONOR_SIGNED_ZEROS it is best to treat contains_p as {-0.0,0.0} being
one thing (just not singleton_p) and not bother with details like whether
a range ends or starts with -0.0 or 0.0, either of them would work the same.
And for !MODE_HAS_SIGNED_ZEROS, obviously 0.0 can be singleton_p.
*head explodes*
Ok, I think I can add a zero property we can track (like we do for
NAN), and set it appropriately at constant creation and upon results
from copysign/signbit. However, I am running out of time before
Cauldron, so I think I'll just treat +-0.0 ambiguously for now, and do
that as a follow-up.
We definitely want to be able to track +-0.0 and distinguish between
them. IIRC there's cases where you can start eliminating comparisons
and arithmetic once you start tracking -0.0 state.
Jeff
