From: "Roger Sayle" <roger@nextmovesoftware.com>
To: <gcc-patches@gcc.gnu.org>
Subject: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans
Date: Fri, 26 Apr 2024 09:17:35 +0100 [thread overview]
Message-ID: <009201da97b2$325fc140$971f43c0$@nextmovesoftware.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
This patch addresses PR middle-end/111701 where optimization of signbit(x*x)
using tree_nonnegative_p incorrectly eliminates a floating point
multiplication when the operands may potentially be signaling NaNs.
The above bug fix also provides a solution or work-around to the tricky
issue in PR middle-end/111701, that the results of IEEE operations on NaNs
are specified to return a NaN result, but fail to (precisely) specify
the exact NaN representation of this result. Hence for the operation
"-NaN*-NaN" different hardware implementations (targets) return different
results. Ultimately knowing what the resulting NaN "payload" of an
operation is can only be known by executing that operation at run-time,
and I'd suggest that GCC's -fsignaling-nans provides a mechanism for
handling code that uses NaN representations for communication/signaling
(which is a different but related concept to IEEE's sNaN).
One nice thing about this patch, which may or may not be a P2 regression
fix, is that it only affects (improves) code compiled with -fsignaling-nans
so should be extremely safe even for this point in stage 3.
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures. Ok for mainline?
2024-04-26 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/111701
* fold-const.cc (tree_binary_nonnegative_warnv_p) <case MULT_EXPR>:
Split handling of floating point and integer types. For equal
floating point operands, avoid optimization if the operand may be
a signaling NaN.
gcc/testsuite/ChangeLog
PR middle-end/111701
* gcc.dg/pr111701-1.c: New test case.
* gcc.dg/pr111701-2.c: Likewise.
Thanks in advance,
Roger
--
[-- Attachment #2: patchnn2.txt --]
[-- Type: text/plain, Size: 2223 bytes --]
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 7b26896..f7f174d 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15076,16 +15076,27 @@ tree_binary_nonnegative_warnv_p (enum tree_code code, tree type, tree op0,
break;
case MULT_EXPR:
- if (FLOAT_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
+ if (FLOAT_TYPE_P (type))
{
- /* x * x is always non-negative for floating point x
- or without overflow. */
+ /* x * x is non-negative for floating point x except
+ that -NaN*-NaN may return -NaN. PR middle-end/111701. */
+ if (operand_equal_p (op0, op1, 0))
+ {
+ if (!tree_expr_maybe_signaling_nan_p (op0) || RECURSE (op0))
+ return true;
+ }
+ else if (RECURSE (op0) && RECURSE (op1))
+ return true;
+ }
+
+ if (ANY_INTEGRAL_TYPE_P (type)
+ && TYPE_OVERFLOW_UNDEFINED (type))
+ {
+ /* x * x is always non-negative without overflow. */
if (operand_equal_p (op0, op1, 0)
|| (RECURSE (op0) && RECURSE (op1)))
{
- if (ANY_INTEGRAL_TYPE_P (type)
- && TYPE_OVERFLOW_UNDEFINED (type))
- *strict_overflow_p = true;
+ *strict_overflow_p = true;
return true;
}
}
diff --git a/gcc/testsuite/gcc.dg/pr111701-1.c b/gcc/testsuite/gcc.dg/pr111701-1.c
new file mode 100644
index 0000000..5cbfac2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111701-1.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsignaling-nans -fdump-tree-optimized" } */
+
+int foo(double x)
+{
+ return __builtin_signbit(x*x);
+}
+
+int bar(float x)
+{
+ return __builtin_signbit(x*x);
+}
+
+/* { dg-final { scan-tree-dump-times " \\* " 2 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/pr111701-2.c b/gcc/testsuite/gcc.dg/pr111701-2.c
new file mode 100644
index 0000000..f79c7ba
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111701-2.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int foo(double x)
+{
+ return __builtin_signbit(x*x);
+}
+
+int bar(float x)
+{
+ return __builtin_signbit(x*x);
+}
+
+/* { dg-final { scan-tree-dump-not " \\* " "optimized" } } */
next reply other threads:[~2024-04-26 8:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 8:17 Roger Sayle [this message]
2024-05-02 9:19 ` Richard Biener
2024-05-02 9:34 ` Roger Sayle
2024-05-02 10:09 ` Richard Biener
2024-05-02 13:48 ` Roger Sayle
2024-05-03 10:22 ` Richard Biener
2024-05-07 20:44 ` Joseph Myers
2024-05-08 7:19 ` Richard Biener
2024-05-09 20:29 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='009201da97b2$325fc140$971f43c0$@nextmovesoftware.com' \
--to=roger@nextmovesoftware.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).