On 3/15/2022 2:03 AM, Roger Sayle wrote:
-----Original Message-----
From: Richard Biener <richard.guent...@gmail.com>
Sent: 15 March 2022 07:29
To: Roger Sayle <ro...@nextmovesoftware.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP
comparisons.
On Mon, Mar 14, 2022 at 8:26 PM Roger Sayle
<ro...@nextmovesoftware.com> wrote:
I've been wondering about the possible performance/missed-optimization
impact of my patch for PR middle-end/98420 and similar IEEE
correctness fixes that disable constant folding optimizations when worrying
about -0.0.
In the common situation where the floating point result is used by a
FP comparison, there's no distinction between +0.0 and -0.0, so some
HONOR_SIGNED_ZEROS optimizations that we'd usually disable, are safe.
Consider the following interesting example:
int foo(int x, double y) {
return (x * 0.0) < y;
}
Although we know that x (when converted to double) can't be NaN or
Inf, we still worry that for negative values of x that (x * 0.0) may
be -0.0 and so perform the multiplication at run-time. But in this
case, the result of the comparison (-0.0 < y) will be exactly the same
as (+0.0 < y) for any y, hence the above may be safely constant folded to "0.0 <
y"
avoiding the multiplication at run-time.
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check with no new failures, and allows GCC to continue to
optimize cases that we optimized in GCC 11 (without regard to correctness).
Ok for mainline?
Isn't that something that gimple-ssa-backprop.c is designed to handle? I wonder
if you can see whether the signed zero speciality can be retrofitted there?
It currently tracks "sign does not matter", so possibly another state, "sign of
zero does not matter" could be introduced there.
Two questions. Would adding tracking of "sign of zero does not matter" to
gimple-ssa-backprop.c be suitable for stage4? Secondly, even if
gimple-ssa-backprop.c
performed this kind of optimization, would that be a reason not to support
these transformations in match.pd? Perhaps someone could open a missed
optimization PR for backprop in Bugzilla, but the above patch still needs to be
reviewed on its own merits.
Can't see how it's appropriate for stage4, but definitely interesting
for gcc-13.
It'd fit well into some of the Ranger plans too -- Aldy and Andrew have
been talking about tracking the special FP values in Ranger. This is
related, though not exactly the same since rather than tracking the
special value, you're tracking if those special values actually matter.
If you're going to do more work in this space, you might want to reach
out to Aldy and Andrew to see if there's space for collaboration.
Speaking of tree-ssa passes that could be improved, I was wondering whether
you could review my EVRP patch to fix regression PR/102950. Pretty please?
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589569.html
I forwarded this to Aldy & Andrew. I suspect they missed it.
Thanks (as always),
No, thank you. I'm so happy to see you contributing to GCC regularly again!
Jeff
