PR tree-optimization/109274 -Fix compute_operand when op1 == op2 symbolically.
Commit Message
On 3/24/23 12:36, Jakub Jelinek wrote:
> On Fri, Mar 24, 2023 at 11:52:30AM -0400, Andrew MacLeod wrote:
>> Thanks.. Ive incorporated it into my commit too.
> Note, both my earlier version of the patch and your patch regress:
> FAIL: gcc.dg/tree-ssa/vrp-float-3a.c scan-tree-dump-not evrp "link_error"
> FAIL: gcc.dg/tree-ssa/vrp-float-4a.c scan-tree-dump-not evrp "link_error"
>
> Jakub
>
OK, that was fun.
I commented in the PR, but the root issue is the way I was trying to
communicate symbolic equivalence on operands to the compute_operand
routines.
[1, 1 ]= a_1 != a_1
I was creating a relation record between op1 and op2 indicating they
were equivalent. THis record then gets passed up the gori call chain.
Reality is that this is not a true equivalence... without looking a the
ranges, we dont know that that is true for general application, and and
furthermore, when applied to something like a1 != a1, you can see the
problem...
Once I corrected the value_relation record to create records with the
same operand, things went south.
What we really need is to locally identify when op1 and op2 are the same
symbol, and if there is no other information, pass it locally on that
one statement to the range-op handler.
Then, once we have processed the statement, we invoke the handler for
that statement to cvreate a record which is passed up the chain.
so for:
a_1 = b_4 + 1.0
[1, 1] = (a_1 != a_1)
compute_operand_1 starts with no relation record, recognizes
symbolically op1 and op2 are the same, and passes EQ_EXPR locally as the
op1_op2 relation to the handler for NE_EXPR. That handler utilizes the
range of op2 to detemine whether != is true or not based on knowledge
that op1 and op2 are the same value. (for integer always false, for
float, takes a look at NAN) and produces a result.
Before invoking compute_operand to calculate b_4 with the result of a_1,
handler.op1_op2_relation (lhs);
is invoked to determine if there is a relation generated by the
statement, which will generate (a_1 != a_1), and pass that to compute
operand for use in evaluating b_4.
Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?
Andrew
Comments
On Tue, Mar 28, 2023 at 3:19 PM Andrew MacLeod <amacleod@redhat.com> wrote:
>
> On 3/24/23 12:36, Jakub Jelinek wrote:
> > On Fri, Mar 24, 2023 at 11:52:30AM -0400, Andrew MacLeod wrote:
> >> Thanks.. Ive incorporated it into my commit too.
> > Note, both my earlier version of the patch and your patch regress:
> > FAIL: gcc.dg/tree-ssa/vrp-float-3a.c scan-tree-dump-not evrp "link_error"
> > FAIL: gcc.dg/tree-ssa/vrp-float-4a.c scan-tree-dump-not evrp "link_error"
> >
> > Jakub
> >
> OK, that was fun.
>
> I commented in the PR, but the root issue is the way I was trying to
> communicate symbolic equivalence on operands to the compute_operand
> routines.
>
> [1, 1 ]= a_1 != a_1
>
> I was creating a relation record between op1 and op2 indicating they
> were equivalent. THis record then gets passed up the gori call chain.
>
> Reality is that this is not a true equivalence... without looking a the
> ranges, we dont know that that is true for general application, and and
> furthermore, when applied to something like a1 != a1, you can see the
> problem...
>
> Once I corrected the value_relation record to create records with the
> same operand, things went south.
>
> What we really need is to locally identify when op1 and op2 are the same
> symbol, and if there is no other information, pass it locally on that
> one statement to the range-op handler.
>
> Then, once we have processed the statement, we invoke the handler for
> that statement to cvreate a record which is passed up the chain.
> so for:
>
> a_1 = b_4 + 1.0
> [1, 1] = (a_1 != a_1)
>
> compute_operand_1 starts with no relation record, recognizes
> symbolically op1 and op2 are the same, and passes EQ_EXPR locally as the
> op1_op2 relation to the handler for NE_EXPR. That handler utilizes the
> range of op2 to detemine whether != is true or not based on knowledge
> that op1 and op2 are the same value. (for integer always false, for
> float, takes a look at NAN) and produces a result.
>
> Before invoking compute_operand to calculate b_4 with the result of a_1,
> handler.op1_op2_relation (lhs);
> is invoked to determine if there is a relation generated by the
> statement, which will generate (a_1 != a_1), and pass that to compute
> operand for use in evaluating b_4.
>
> Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?
LGTM.
Thanks,
Richard.
> Andrew
commit 97f9c24fe471b9701cf3ba89901e146a9c52f3ad
Author: Andrew MacLeod <amacleod@redhat.com>
Date: Fri Mar 24 11:21:20 2023 -0400
Fix compute_operand when op1 == op2 symbolically.
First, class value_relation should not sanitize records. just create
what is asked.
Second., if there is not a relation record, compute_operand was
creating one for op1 == op2 if op1 and op2 were the same symbol. This
is not the correct way to communicate the information, as that record
will continue to be passed along the GORI unwind chain.
Instead, simply pass that information locally to the opX_range routine
for only the current statement.
PR tree-optimization/109265
PR tree-optimization/109274
gcc/
* gimple-range-gori.cc (gori_compute::compute_operand_range): Do
not create a relation record is op1 and op2 are the same symbol.
(gori_compute::compute_operand1_range): Pass op1 == op2 to the
handler for this stmt, but create a new record only if this statement
generates a relation based on the ranges.
(gori_compute::compute_operand2_range): Ditto.
* value-relation.h (value_relation::set_relation): Always create the
record that is requested.
gcc/testsuite/
* gcc.dg/pr109274.c: New.
* gfortran.dg/pr109265.f90: New.
@@ -623,21 +623,6 @@ gori_compute::compute_operand_range (vrange &r, gimple *stmt,
tree op1 = gimple_range_ssa_p (handler.operand1 ());
tree op2 = gimple_range_ssa_p (handler.operand2 ());
- // If there is a relation, use it instead of any passed in. This will allow
- // multiple relations to be processed in compound logicals.
- if (op1 && op2)
- {
- relation_kind k = handler.op1_op2_relation (lhs);
- // If there is no relation, and op1 == op2, create a relation.
- if (!vrel_ptr && k == VREL_VARYING && op1 == op2)
- k = VREL_EQ;
- if (k != VREL_VARYING)
- {
- vrel.set_relation (k, op1, op2);
- vrel_ptr = &vrel;
- }
- }
-
// Handle end of lookup first.
if (op1 == name)
return compute_operand1_range (r, handler, lhs, name, src, vrel_ptr);
@@ -1093,6 +1078,7 @@ gori_compute::compute_operand1_range (vrange &r,
const vrange &lhs, tree name,
fur_source &src, value_relation *rel)
{
+ value_relation local_rel;
gimple *stmt = handler.stmt ();
tree op1 = handler.operand1 ();
tree op2 = handler.operand2 ();
@@ -1101,6 +1087,7 @@ gori_compute::compute_operand1_range (vrange &r,
relation_trio trio;
if (rel)
trio = rel->create_trio (lhs_name, op1, op2);
+ relation_kind op_op = trio.op1_op2 ();
Value_Range op1_range (TREE_TYPE (op1));
Value_Range tmp (TREE_TYPE (op1));
@@ -1113,10 +1100,26 @@ gori_compute::compute_operand1_range (vrange &r,
if (op2)
{
src.get_operand (op2_range, op2);
- relation_kind op_op = trio.op1_op2 ();
+
+ // If there is a relation betwen op1 and op2, use it instead.
+ // This allows multiple relations to be processed in compound logicals.
+ if (gimple_range_ssa_p (op1) && gimple_range_ssa_p (op2))
+ {
+ relation_kind k = handler.op1_op2_relation (lhs);
+ if (k != VREL_VARYING)
+ {
+ op_op = k;
+ local_rel.set_relation (op_op, op1, op2);
+ rel = &local_rel;
+ }
+ }
+
if (op_op != VREL_VARYING)
refine_using_relation (op1, op1_range, op2, op2_range, src, op_op);
+ // If op1 == op2, create a new trio for just this call.
+ if (op1 == op2 && gimple_range_ssa_p (op1))
+ trio = relation_trio (trio.lhs_op1 (), trio.lhs_op2 (), VREL_EQ);
if (!handler.calc_op1 (tmp, lhs, op2_range, trio))
return false;
}
@@ -1185,6 +1188,7 @@ gori_compute::compute_operand2_range (vrange &r,
const vrange &lhs, tree name,
fur_source &src, value_relation *rel)
{
+ value_relation local_rel;
gimple *stmt = handler.stmt ();
tree op1 = handler.operand1 ();
tree op2 = handler.operand2 ();
@@ -1201,9 +1205,26 @@ gori_compute::compute_operand2_range (vrange &r,
if (rel)
trio = rel->create_trio (lhs_name, op1, op2);
relation_kind op_op = trio.op1_op2 ();
+
+ // If there is a relation betwen op1 and op2, use it instead.
+ // This allows multiple relations to be processed in compound logicals.
+ if (gimple_range_ssa_p (op1) && gimple_range_ssa_p (op2))
+ {
+ relation_kind k = handler.op1_op2_relation (lhs);
+ if (k != VREL_VARYING)
+ {
+ op_op = k;
+ local_rel.set_relation (op_op, op1, op2);
+ rel = &local_rel;
+ }
+ }
+
if (op_op != VREL_VARYING)
refine_using_relation (op1, op1_range, op2, op2_range, src, op_op);
+ // If op1 == op2, create a new trio for this stmt.
+ if (op1 == op2 && gimple_range_ssa_p (op1))
+ trio = relation_trio (trio.lhs_op1 (), trio.lhs_op2 (), VREL_EQ);
// Intersect with range for op2 based on lhs and op1.
if (!handler.calc_op2 (tmp, lhs, op1_range, trio))
return false;
new file mode 100644
@@ -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;
+}
+
new file mode 100644
@@ -0,0 +1,39 @@
+! PR tree-optimization/109265
+! { dg-do compile }
+! { dg-options "-O3 -w" }
+
+module pr109265
+ integer, parameter :: r8 = selected_real_kind (12)
+contains
+ subroutine foo (b, c, d, e, f)
+ implicit none
+ logical :: b
+ real (kind = r8) :: c, d, e, f, i
+ if (b) then
+ c = bar (c * d, e)
+ i = bar (f, c)
+ call baz (i)
+ call baz (-i)
+ end if
+ end subroutine foo
+ function bar (a, b)
+ implicit none
+ real (kind = r8) :: bar
+ real (kind = r8) :: a, b
+ bar = a + b
+ end function bar
+ subroutine baz (b)
+ implicit none
+ real (kind = r8) :: b, d, e, f, g, h, i
+ d = b
+ i = 0
+ e = d
+ f = d
+ g = d
+ 10 continue
+ if ((e.eq.d) .and. (f.eq.d) .and. (g.eq.d) .and. (h.eq.d)) then
+ h = i
+ goto 10
+ end if
+ end subroutine baz
+end module pr109265
@@ -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;