From: Andrew MacLeod <amacleod@redhat.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Jakub Jelinek <jakub@redhat.com>,
"hernandez, aldy" <aldyh@redhat.com>,
Richard Biener <richard.guenther@gmail.com>
Subject: [PATCH] PR tree-optimization/108447 - Do not try to logical fold floating point relations.
Date: Wed, 25 Jan 2023 13:05:09 -0500 [thread overview]
Message-ID: <0780922f-99b5-96fc-b921-9e00652f9741@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
This boils down to a single place where we are trying to do things with
relations in ranger that are simply not safe when we need to honor NANs.
I think we can avoid all the other shuffling of relations, and simply
not perform this optimization when it comes to floats.
The case the routine handles is:
c_2 = a_6 > b_7
c_3 = a_6 < b_7
c_4 = c_2 && c_3
c_2 and c_3 can never be true at the same time, Therefore c_4 can always
resolve to false based purely on the relations.
Range-ops is unable to do this optimization directly as it requires
examining things from outside the statement, and is not easily
communicated a simple relation to operator_logical_and.
This routine proceeds to look at the definitions of c_2 and c_3, tries
to determine if there are common operands, and queries for any relations
between them. If it turns out there is something, depending on whether
its && or || , we use intersection or union to determine if the result
of the logical operation can be folded. If HONOR_NANS is true for the
float type, then we cannot do this optimization, and bail early.
At this point I do not think we need to do any of the other things
proposed to relations, so we don't need either of the other 2 patches
this release.
Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?
Andrew
[-- Attachment #2: F --]
[-- Type: text/plain, Size: 2026 bytes --]
commit 0b080e9579045dd054e9b3289d123d6b66567e3e
Author: Andrew MacLeod <amacleod@redhat.com>
Date: Wed Jan 25 11:13:23 2023 -0500
Do not try to logical fold floating point relations.
relation_fold_and_or looks for relations among common operands feeding
logical ands and ors. With no knowledge of NANs, it should not attempt
to do this with floating point ssa names.
PR tree-optimization/108447
gcc/
* gimple-range-fold.cc (old_using_range::relation_fold_and_or):
Do not attempt to fold HONOR_NAN types.
gcc/testsuite/
* gcc.dg/pr108447.c: New.
diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 91eb6298254..9c5359a3fc6 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -1039,6 +1039,9 @@ fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s,
if (!ssa1_dep1 || !ssa1_dep2 || !ssa2_dep1 || !ssa2_dep2)
return;
+ if (HONOR_NANS (TREE_TYPE (ssa1_dep1)))
+ return;
+
// Make sure they are the same dependencies, and detect the order of the
// relationship.
bool reverse_op2 = true;
diff --git a/gcc/testsuite/gcc.dg/pr108447.c b/gcc/testsuite/gcc.dg/pr108447.c
new file mode 100644
index 00000000000..cfbaba6d0aa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108447.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+__attribute__((noipa)) int
+foo (float x, float y)
+{
+ _Bool cmp1 = x <= y;
+ _Bool cmp2 = x >= y;
+ if (cmp1 && cmp2)
+ return 1;
+ else if (!cmp1 && !cmp2)
+ return -1;
+ return 0;
+}
+
+int
+main ()
+{
+ if (foo (0.0f, __builtin_nanf ("")) != -1)
+ __builtin_abort ();
+ if (foo (__builtin_nanf (""), -42.0f) != -1)
+ __builtin_abort ();
+ if (foo (0.0f, -0.0f) != 1)
+ __builtin_abort ();
+ if (foo (42.0f, 42.0f) != 1)
+ __builtin_abort ();
+ if (foo (42.0f, -0.0f) != 0)
+ __builtin_abort ();
+ if (foo (0.0f, -42.0f) != 0)
+ __builtin_abort ();
+ return 0;
+}
+
next reply other threads:[~2023-01-25 18:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 18:05 Andrew MacLeod [this message]
2023-01-26 7:09 ` Richard Biener
2023-01-26 7:13 ` Richard Biener
2023-01-26 14:24 ` Andrew MacLeod
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=0780922f-99b5-96fc-b921-9e00652f9741@redhat.com \
--to=amacleod@redhat.com \
--cc=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=richard.guenther@gmail.com \
/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).