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.
Thanks,
Richard.
>
> 2022-03-14 Roger Sayle <ro...@nextmovesoftware.com>
>
> gcc/ChangeLog
> * match.pd (X CMP (Y-Y) -> X CMP 0.0): New transformation.
> (X CMP (Y * 0.0) -> X CMP 0.0): Likewise.
> (X CMP X -> true): Test tree_expr_maybe_nan_p instead of HONOR_NANS.
> (X LTGT X -> false): Enable if X is not tree_expr_maybe_nan_p, as
> this can't trap/signal.
>
> gcc/testsuite/ChangeLog
> * gcc.dg/fold-compare-9.c: New test case.
>
>
> Thanks in advance,
> Roger
> --
>
