From: Andrew MacLeod <amacleod@redhat.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>,
Jakub Jelinek <jakub@redhat.com>,
Richard Biener <richard.guenther@gmail.com>
Subject: [PATCH] PR tree-optimization/109274 - Don't interpret contents of a value_relation record.
Date: Fri, 24 Mar 2023 11:08:54 -0400 [thread overview]
Message-ID: <2e0b9177-f8ce-d55a-d6bb-71eb89a9700d@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
Before floating point relations were added, we tried to sanitize
value-relation records to not include non-sensensical records... ie x !=
x or x < x. Instead, we made a VREL_VARYING record with no operands.
When floating point relation support was added, some of these were no
longer non-sensical, AND we expanded the use of value_relation records
into GORI shortly thereafter.
As a result, this sanitization is no longer needed, nor desired. The
Oracle does not create records with op1 == op2 already, so its only
within GORI that these records can exist, and we shouldn't try to
interpret them.
The bug occurs because the "sanitized" records doesn't set op1 and op2,
and changes the relation to VARYING.. and we expected the operands it
to be set the way they were specified. We should not be setting a
VREL_VARYING record if asked to set something else. In fact, we are
missing some opportunities because we are trying to FP range-ops that
op1 != op1 but its getting transformed into a VREL_VARYING record and
not communicated properly.
Currently bootstrapping on x86_64-pc-linux-gnu and assuming no
regressions, OK for trunk?
Andrew
[-- Attachment #2: 274.diff --]
[-- Type: text/x-patch, Size: 2172 bytes --]
commit 1f02961b23976d35b10e2399708c6eb00632f9d6
Author: Andrew MacLeod <amacleod@redhat.com>
Date: Fri Mar 24 09:18:33 2023 -0400
Don't interpret contents of a value_relation record.
before floating point relations were added, we tried to sanitize
value-relation records to not include non-sensensical records... ie
x != x or x < x. INstead, we made a VREL_VARYING record with no
operands.
When floating point relations were supported, some of these were no
longer non-sensical, AND we expanded the use of value_relation records
into GORI.
As a result, this sanitization is no longer needed. The Oracle
does not create records with op1 == op2, so its only within GORI
that these records can exist, and we shouldnt try to interpret them.
The bug occurs because the "sanitized" records doesnt set op1 anmd op2,
but we have a record so expected it to be set.
PR tree-optimization/109265
PR tree-optimization/109274
gcc/
* value-relation.h (value_relation::set_relation): Always create the
record that is requested.
gcc/testsuite/
* gcc.dg/pr109274.c: New.
diff --git a/gcc/testsuite/gcc.dg/pr109274.c b/gcc/testsuite/gcc.dg/pr109274.c
new file mode 100644
index 00000000000..5dbc0232f8e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr109274.c
@@ -0,0 +1,16 @@
+/* PR tree-optimization/109274 */
+/* { dg-do compile } */
+/* { dg-options "-O2 " } */
+
+float a, b, c;
+int d;
+float bar (void);
+
+void
+foo (void)
+{
+ a = 0 * -(2.0f * c);
+ d = a != a ? 0 : bar ();
+ b = c;
+}
+
diff --git a/gcc/value-relation.h b/gcc/value-relation.h
index 36a75862cc7..3177ecb1ad0 100644
--- a/gcc/value-relation.h
+++ b/gcc/value-relation.h
@@ -445,13 +445,6 @@ value_relation::set_relation (relation_kind r, tree n1, tree n2)
{
gcc_checking_assert (TREE_CODE (n1) == SSA_NAME
&& TREE_CODE (n2) == SSA_NAME);
- if (n1 == n2 && r != VREL_EQ)
- {
- related = VREL_VARYING;
- name1 = NULL_TREE;
- name2 = NULL_TREE;
- return;
- }
related = r;
name1 = n1;
name2 = n2;
next reply other threads:[~2023-03-24 15:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 15:08 Andrew MacLeod [this message]
2023-03-24 15:15 ` Jakub Jelinek
2023-03-24 15:52 ` Andrew MacLeod
2023-03-24 16:36 ` Jakub Jelinek
2023-03-28 13:19 ` [PATCH] PR tree-optimization/109274 -Fix compute_operand when op1 == op2 symbolically Andrew MacLeod
2023-03-28 13:28 ` Richard Biener
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=2e0b9177-f8ce-d55a-d6bb-71eb89a9700d@redhat.com \
--to=amacleod@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).