[tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
law@redhat.com
law@redhat.com
Wed Jun 11 14:19:00 GMT 2003
20030530-2.c is currently failing because we fail to recognize that
"a + b" and "b + a" are equivalent expressions. There's two underlying
problems which need to be addressed to detect such redundancies.
1. avail_expr_hash needs to ignore ordering of operands it the
uses array. That's trivial since iterative_hash_expr was recently
updated to handle SSA_NAME and the like.
2. avail_expr_eq needs to use something more intelligent that
simple_cst_equal for comparing trees (simple_cst_equal doesn't
handle commutative operands). Luckily operand_equal_p is handy :-)
Doing these things exposes a latent but in how we set may_optimize_p for
expresssions. Namely we set it for expressions in which TREE_SIDE_EFFECTS
is set. tsk tsk.
This patch fixes all those issues. And (of course) gcc.dg/tree-ssa/20030530-2
now passes :-)
* tree-ssa.c (rewrite_and_optimize_stmt): Improve/correct setting of
may_optimize_p. Simplify later code knowing may_optimize_p is
correctly set.
(avail_expr_hash): Do not use iterative_hash_object or deal with
SSA names for real operands. Instead use iterative_hash_expr
which handles both.
(avail_expr_eq): Use operand_equal_p to test for equality.
Index: tree-ssa.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Attic/tree-ssa.c,v
retrieving revision 1.1.4.89
diff -c -3 -p -r1.1.4.89 tree-ssa.c
*** tree-ssa.c 11 Jun 2003 01:22:25 -0000 1.1.4.89
--- tree-ssa.c 11 Jun 2003 14:07:13 -0000
*************** rewrite_and_optimize_stmt (block_stmt_it
*** 2068,2078 ****
nor volatile references and no side effects (i.e., no VDEFs). */
may_optimize_p = !ann->makes_aliased_stores
&& !ann->has_volatile_ops
! && vdefs == NULL;
! if (may_optimize_p
! && def_p
! && TREE_CODE (TREE_OPERAND (stmt, 1)) != CALL_EXPR)
{
/* Check if the RHS of the assignment has been computed before. If
so, use the LHS of the previously computed statement as the
--- 2068,2079 ----
nor volatile references and no side effects (i.e., no VDEFs). */
may_optimize_p = !ann->makes_aliased_stores
&& !ann->has_volatile_ops
! && vdefs == NULL
! && def_p
! && ! TREE_SIDE_EFFECTS (TREE_OPERAND (stmt, 1))
! && ! TREE_CODE (TREE_OPERAND (stmt, 1)) != CALL_EXPR;
! if (may_optimize_p)
{
/* Check if the RHS of the assignment has been computed before. If
so, use the LHS of the previously computed statement as the
*************** avail_expr_hash (const void *p)
*** 2587,2605 ****
size_t i;
varray_type ops;
tree stmt = (tree) p;
- enum tree_code code;
rhs = TREE_OPERAND (stmt, 1);
! code = TREE_CODE (rhs);
! val = iterative_hash_object (code, val);
!
! /* Add the SSA version numbers of every use operand. */
! ops = use_ops (stmt);
! for (i = 0; ops && i < VARRAY_ACTIVE_SIZE (ops); i++)
! {
! tree op = *((tree *) VARRAY_GENERIC_PTR (ops, i));
! val = iterative_hash_expr (op, val);
! }
/* Add the SSA version numbers of every vuse operand. This is important
because compound variables like arrays are not renamed in the
--- 2588,2599 ----
size_t i;
varray_type ops;
tree stmt = (tree) p;
+ /* iterative_hash_expr knows how to deal with any expression and
+ deals with commutative operators as well, so just use it instead
+ of duplicating such complexities here. */
rhs = TREE_OPERAND (stmt, 1);
! val = iterative_hash_expr (rhs, val);
/* Add the SSA version numbers of every vuse operand. This is important
because compound variables like arrays are not renamed in the
*************** avail_expr_eq (const void *p1, const voi
*** 2626,2633 ****
/* In case of a collision, both RHS have to be identical and have the
same VUSE operands. */
! if (TREE_CODE (rhs1) == TREE_CODE (rhs2)
! && simple_cst_equal (rhs1, rhs2) == 1)
{
varray_type ops1 = vuse_ops (s1);
varray_type ops2 = vuse_ops (s2);
--- 2620,2626 ----
/* In case of a collision, both RHS have to be identical and have the
same VUSE operands. */
! if (TREE_CODE (rhs1) == TREE_CODE (rhs2) && operand_equal_p (rhs1, rhs2,
0))
{
varray_type ops1 = vuse_ops (s1);
varray_type ops2 = vuse_ops (s2);
More information about the Gcc-patches
mailing list