[PATCH] PR tree-optimization/108139 - Don't use PHI equivalences in range-on-entry.

[PATCH] PR tree-optimization/108139 - Don't use PHI equivalences in range-on-entry.

[Andrew MacLeod]

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

our use of equivalences on range-on-entry calculations cause an issue 
through a PHI node when a back edge is involved.  ie
    a = VARYING
    <...>
bb5
    b = PHI <UNDEFINED(2), a (5)>
bb6
    if (a != 0)
      goto bb5

since the value of b is undefined on the edge 2->5, we ignore it. The 
range of a on the edge 6->5 is ~[0,0]
we calculate the range of b to be ~[0,0].   we also provide an 
equivalency between a and b.

Unfortunately the on-entry code looks at equivalencies, and says, "hey, 
a and b are equivalent, so we can use the range of b instead"

So it now thinks a is ~[0,0] and folds away the condition.

The problem is that b can be considered equivalent to a, but the 
converse is not true, because there is a path (2->5) upon which a is not 
equivalent to b.  we have no way to represent a one way equivalence at 
the moment. This patch avoid using that relation in range-on-entry 
calculations.

Perhaps next release I'll add a specific kind of one way equivalence for 
this kind of situation.

Bootstraps on x86_64-pc-linux-gnu with no regressions. OK?

Andrew

[-- Attachment #2: 108139.patch --]
[-- Type: text/x-patch, Size: 2215 bytes --]

commit ecf19b6eb6f8e17d8d148e3c6627bd2151766420
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Fri Dec 16 16:53:31 2022 -0500

    Don't use PHI equivalences in range-on-entry.
    
    If there is only one argument to a PHI which is defined, an equivalency is
    created between the def and the argument.  It is safe to consider the def
    equal to the argument, but it is dangerous to assume the argument is also
    equivalent to the def as there may be branches which change the range on the
    path to the PHI on that argument
    
    This patch avoid using that relation in range-on-entry calculations.
    
            PR tree-optimization/108139
            gcc/
            * gimple-range-cache.cc (ranger_cache::fill_block_cache): Do not
            use equivalences originating from PHIS.
    
            gcc/testsuite/
            * gcc.dg/pr108139.c: New.

diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index ce5a0c8155e..9848d140242 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -1235,6 +1235,13 @@ ranger_cache::fill_block_cache (tree name, basic_block bb, basic_block def_bb)
 	      if (!m_gori.has_edge_range_p (equiv_name))
 		continue;
 
+	      // PR 108139. It is hazardous to assume an equivalence with
+	      // a PHI is the same value.  The PHI may be an equivalence
+	      // via UNDEFINED arguments which is really a one way equivalence.
+	      // PHIDEF == name, but name may not be == PHIDEF.
+	      if (is_a<gphi *> (SSA_NAME_DEF_STMT (equiv_name)))
+		continue;
+
 	      // Check if the equiv definition dominates this block
 	      if (equiv_bb == bb ||
 		  (equiv_bb && !dominated_by_p (CDI_DOMINATORS, bb, equiv_bb)))
diff --git a/gcc/testsuite/gcc.dg/pr108139.c b/gcc/testsuite/gcc.dg/pr108139.c
new file mode 100644
index 00000000000..6f224e3ce62
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108139.c
@@ -0,0 +1,18 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O1 -ftree-vrp -fdump-tree-vrp" } */
+
+int a, b;
+int main() {
+  int c;
+  if (a > 1)
+    a++;
+  while (a)
+    if (c == b)
+      c = a;
+  return 0;
+}
+
+
+/* { dg-final { scan-tree-dump-not "Folding predicate" "vrp2" } } */
+
+

Re: [PATCH] PR tree-optimization/108139 - Don't use PHI equivalences in range-on-entry.

[Richard Biener]

On Mon, Dec 19, 2022 at 3:57 PM Andrew MacLeod via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> our use of equivalences on range-on-entry calculations cause an issue
> through a PHI node when a back edge is involved.  ie
>     a = VARYING
>     <...>
> bb5
>     b = PHI <UNDEFINED(2), a (5)>
> bb6
>     if (a != 0)
>       goto bb5
>
> since the value of b is undefined on the edge 2->5, we ignore it. The
> range of a on the edge 6->5 is ~[0,0]
> we calculate the range of b to be ~[0,0].   we also provide an
> equivalency between a and b.
>
> Unfortunately the on-entry code looks at equivalencies, and says, "hey,
> a and b are equivalent, so we can use the range of b instead"
>
> So it now thinks a is ~[0,0] and folds away the condition.
>
> The problem is that b can be considered equivalent to a, but the
> converse is not true, because there is a path (2->5) upon which a is not
> equivalent to b.  we have no way to represent a one way equivalence at
> the moment. This patch avoid using that relation in range-on-entry
> calculations.
>
> Perhaps next release I'll add a specific kind of one way equivalence for
> this kind of situation.
>
> Bootstraps on x86_64-pc-linux-gnu with no regressions. OK?

OK.  Note that equivalences across backedges can also result in
values from one cycle iteration to be used in another - a SSA def
in a SSA cycle can have different values.

Richard.

>
> Andrew