------- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-14 11:11
-------
If we watch what happens to the multiplication after VRP, we see that it is
possibly an immediate uses problem:
Hardware watchpoint 6: *(union tree_node **) 3082785444
Old value = (union tree_node *) 0xb7c793dc
New value = (union tree_node *) 0xb7c7971c
set_ssa_use_from_ptr (use=0xb7c7a0bc, val=0xb7c7971c)
at /home/richard/src/gcc-4_1-branch/gcc/tree-flow-inline.h:330
330 link_imm_use (use, val);
#0 set_ssa_use_from_ptr (use=0xb7c7a0bc, val=0xb7c7971c)
at /home/richard/src/gcc-4_1-branch/gcc/tree-flow-inline.h:330
#1 0x080d3ed2 in maybe_replace_use (use_p=0xb7c7a0bc)
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:1386
#2 0x080d3d05 in rewrite_update_stmt (walk_data=0xbfaa5f50, bb=0xb7bfa460, si=
{tsi = {ptr = 0xb7bf8f78, container = 0xb7c78018}, bb = 0xb7bfa460})
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:1465
#3 0x080f1573 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa460)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:196
#4 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa410)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#5 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa5f0)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#6 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa4b0)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#7 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa640)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#8 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa550)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#9 0x080d42c4 in rewrite_blocks (entry=0xb7bfa550, what=REWRITE_UPDATE,
blocks=0x86ab0d8)
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:1616
#10 0x080d6d10 in update_ssa (update_flags=256)
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:2798
#11 0x08403f38 in insert_range_assertions ()
at /home/richard/src/gcc-4_1-branch/gcc/tree-vrp.c:2960
#12 0x08406ce7 in execute_vrp ()
at /home/richard/src/gcc-4_1-branch/gcc/tree-vrp.c:4176
it changes a few times until finally it settles at the wrong solution.
It get's magically fixed if I disable swapping tree operands in
get_expr_operands () (WTF!?) - so this seems to be an operand-scanner
vs. update_ssa interaction?
Index: tree-ssa-operands.c
===================================================================
*** tree-ssa-operands.c (revision 117726)
--- tree-ssa-operands.c (working copy)
*************** get_expr_operands (tree stmt, tree *expr
*** 1257,1295 ****
case ASSERT_EXPR:
do_binary:
{
- tree op0 = TREE_OPERAND (expr, 0);
- tree op1 = TREE_OPERAND (expr, 1);
-
- /* If it would be profitable to swap the operands, then do so to
- canonicalize the statement, enabling better optimization.
-
- By placing canonicalization of such expressions here we
- transparently keep statements in canonical form, even
- when the statement is modified. */
- if (tree_swap_operands_p (op0, op1, false))
- {
- /* For relationals we need to swap the operands
- and change the code. */
- if (code == LT_EXPR
- || code == GT_EXPR
- || code == LE_EXPR
- || code == GE_EXPR)
- {
- TREE_SET_CODE (expr, swap_tree_comparison (code));
- swap_tree_operands (stmt,
- &TREE_OPERAND (expr, 0),
- &TREE_OPERAND (expr, 1));
- }
-
- /* For a commutative operator we can just swap the operands. */
- else if (commutative_tree_code (code))
- {
- swap_tree_operands (stmt,
- &TREE_OPERAND (expr, 0),
- &TREE_OPERAND (expr, 1));
- }
- }
-
get_expr_operands (stmt, &TREE_OPERAND (expr, 0), flags);
get_expr_operands (stmt, &TREE_OPERAND (expr, 1), flags);
return;
--- 1257,1262 ----
note this patch seems to be in mainline already!? My archology skills are
not good enough to figure out when it was gone.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
