PR tree-optimization/105458 - Check for equivalence after merging relations.

Message ID df503963-2b9d-cc87-ece9-e85ca0766ed6@redhat.com
State New
Headers
Series PR tree-optimization/105458 - Check for equivalence after merging relations. |

Commit Message

Andrew MacLeod May 17, 2022, 3:45 p.m. UTC
  Sorry, missed this one earlier.

When we register a relation, such as LE_EXPR,  we first check if there 
is an existing relation that applies, and if so they are combined. We 
were checking if the relation being registered was an EQ_EXPR, and if 
so, invoked the equivalence oracle.

  I was doing the check for EQ_EXPR first, then merging with any 
existing relation.   In this case, the merge resulted in transforming 
the LE_EXPR into an EQ_EXPR, but the check to invoke the 
equivalence_oracle had already been done, and we got to a place we 
shouldn't have. doh!

The fix is to do the merge first, then check for EQ_EXPR.

The patch is a hair different (due to VREL_*  renames in gcc13), so I've 
attached both patches.

bootstraps on gcc12 and gcc13 with no regressions.  pushed on trunk.

OK for GCC12?

Andrew
  

Comments

Richard Biener May 18, 2022, 5:57 a.m. UTC | #1
On Tue, May 17, 2022 at 5:46 PM Andrew MacLeod via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Sorry, missed this one earlier.
>
> When we register a relation, such as LE_EXPR,  we first check if there
> is an existing relation that applies, and if so they are combined. We
> were checking if the relation being registered was an EQ_EXPR, and if
> so, invoked the equivalence oracle.
>
>   I was doing the check for EQ_EXPR first, then merging with any
> existing relation.   In this case, the merge resulted in transforming
> the LE_EXPR into an EQ_EXPR, but the check to invoke the
> equivalence_oracle had already been done, and we got to a place we
> shouldn't have. doh!
>
> The fix is to do the merge first, then check for EQ_EXPR.
>
> The patch is a hair different (due to VREL_*  renames in gcc13), so I've
> attached both patches.
>
> bootstraps on gcc12 and gcc13 with no regressions.  pushed on trunk.
>
> OK for GCC12?

OK

> Andrew
  

Patch

commit c48fe8d3430e81ddea621c24e9b66d55aadfb316
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue May 17 09:36:39 2022 -0400

    Check for equivalence after merging relations.
    
    When registering a relation, we need to merge with any existing relation
    before checking if it was an equivalence... otherwise it was not being
    handled properly.
    
            gcc/
            PR tree-optimization/105458
            * value-relation.cc (path_oracle::register_relation): Merge, then check
            for equivalence.
    
            gcc/testsuite/
            * gcc.dg/pr105458.c: New.

diff --git a/gcc/testsuite/gcc.dg/pr105458.c b/gcc/testsuite/gcc.dg/pr105458.c
new file mode 100644
index 00000000000..eb58bf21f32
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr105458.c
@@ -0,0 +1,20 @@ 
+/* PR tree-optimization/105458 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -fexpensive-optimizations -fno-tree-dominator-opts " } */
+
+void
+yj (int j4)
+{
+  int t3;
+
+  for (t3 = 0; t3 < 6; ++t3)
+    {
+      short int v4 = t3;
+
+      if (v4 == j4 || v4 > t3)
+        for (;;)
+          {
+          }
+    }
+}
+
diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index 077ab4230a7..a69ad080e47 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -1388,16 +1388,16 @@  path_oracle::register_relation (basic_block bb, relation_kind k, tree ssa1,
       fprintf (dump_file, " (root: bb%d)\n", bb->index);
     }
 
+  relation_kind curr = query_relation (bb, ssa1, ssa2);
+  if (curr != VREL_NONE)
+    k = relation_intersect (curr, k);
+
   if (k == EQ_EXPR)
     {
       register_equiv (bb, ssa1, ssa2);
       return;
     }
 
-  relation_kind curr = query_relation (bb, ssa1, ssa2);
-  if (curr != VREL_NONE)
-    k = relation_intersect (curr, k);
-
   bitmap_set_bit (m_relations.m_names, SSA_NAME_VERSION (ssa1));
   bitmap_set_bit (m_relations.m_names, SSA_NAME_VERSION (ssa2));
   relation_chain *ptr = (relation_chain *) obstack_alloc (&m_chain_obstack,