[COMMITTED] PR tree-optimization/101511 - Allow non-symmetrical equivalences.

[COMMITTED] PR tree-optimization/101511 - Allow non-symmetrical equivalences.

[Andrew MacLeod]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

Equivalences and relations are stored in dominator order.  If they are 
registered in non-dominator order, we sometimes get a little out of sync.

This may miss the occasional optimization opportunity, but is not 
incorrect. When transitive relations are added, the intent is to 
"beef-up" the Implementation and we can put the assert back in to make 
sure things are always symmetrical.

Until then, don't trap if we encounter non-symmetry, just use what is found.

Bootstrapped on x86_64 & powerpc64-unknown-linux-gnu with no 
regressions.  Pushed.

Andrew


[-- Attachment #2: 0003-Allow-non-symmetrical-equivalences.patch --]
[-- Type: text/x-patch, Size: 2659 bytes --]

From d3fa77472b78c5ddada03a1052b229bea11cb76f Mon Sep 17 00:00:00 2001
From: Andrew MacLeod <amacleod@redhat.com>
Date: Mon, 19 Jul 2021 15:54:57 -0400
Subject: [PATCH 3/3] Allow non-symmetrical equivalences.

Don't trap if equivalences are processed out of DOM order, and aren't
completely symmetrical.  We will eventually resolve this, but its OK for now.

	gcc/
	PR tree-optimization/101511
	* value-relation.cc (relation_oracle::query_relation): Check if ssa1
	is in ssa2's equiv set, and don't trap if so.

	gcc/testsuite/
	* g++.dg/pr101511.C: New.
---
 gcc/testsuite/g++.dg/pr101511.C | 22 ++++++++++++++++++++++
 gcc/value-relation.cc           |  8 ++++++--
 2 files changed, 28 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr101511.C

diff --git a/gcc/testsuite/g++.dg/pr101511.C b/gcc/testsuite/g++.dg/pr101511.C
new file mode 100644
index 00000000000..ee2c7fdbc02
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr101511.C
@@ -0,0 +1,22 @@
+// { dg-do compile }
+// { dg-options "-O2 -Wno-div-by-zero" }
+
+void __assert_fail(const char *, const char *, int, const char *)
+    __attribute__((__noreturn__));
+template <typename T> void test_uint() {
+  long __trans_tmp_3, __trans_tmp_1;
+  int Error;
+  for (;;) {
+    {
+      unsigned long Tmp = -1;
+      __trans_tmp_3 = Tmp - Tmp % 0;
+    }
+    Error += 0 == __trans_tmp_3 ? 0 : 1;
+    !Error ? void() : __assert_fail("", "", 3, __PRETTY_FUNCTION__);
+    T Tmp = -1;
+    __trans_tmp_1 = Tmp - Tmp % 0;
+    Error += 0 == __trans_tmp_1 ? 0 : 1;
+    !Error ? void() : __assert_fail("", "", 7, __PRETTY_FUNCTION__);
+  }
+}
+void test() { test_uint<unsigned long>(); }
diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index 43fcab7995a..bcfe388acf1 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -873,11 +873,15 @@ relation_oracle::query_relation (basic_block bb, tree ssa1, tree ssa2)
   if (kind != VREL_NONE)
     return kind;
 
-  // If one is not found, see if there is a relationship between equivalences.
   // If v2 isn't in v1s equiv set, then v1 shouldn't be in v2's set either.
+  // It is possible for out-of-order dominator processing to have an out of
+  // sync set of equivalences..  Down the road, when we do full updates,
+  // change this to an assert to ensure everything is in sync.
   const_bitmap equiv2 = equiv_set (ssa2, bb);
-  gcc_checking_assert (!equiv2 || !bitmap_bit_p (equiv2, v1));
+  if (equiv2 && bitmap_bit_p (equiv2, v1))
+    return EQ_EXPR;
 
+  // If not equal, see if there is a relationship between equivalences.
   if (!equiv1 && !equiv2)
     kind = VREL_NONE;
   else if (!equiv1)
-- 
2.17.2