PR tree-optimization/108139 - Don't use PHI equivalences in range-on-entry.
Commit Message
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
Comments
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
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.
@@ -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)))
new file mode 100644
@@ -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" } } */
+
+