| Message ID | 20141023065643.GF4267@bubble.grove.modra.org |
|---|---|
| State | New |
| Headers | show |
On 10/23/14 00:56, Alan Modra wrote: > PR 63615 was caused by r21642 fixing the accounting of "n_constants" > in simplify_plus_minus. Previously, any expression handled by > simplify_plus_minus that expanded to more than two elements and > contained at least one constant would have resulted in "n_constants" > being larger than one, even if it had only one constant. This had the > effect of setting "canonicalized" for such expressions. > > The missed optimisation had these operands to simplify_plus_minus: > (gdb) p debug_rtx(op0) > (plus:SI (reg:SI 0 ax [96]) > (const_int 1 [0x1])) > $1 = void > (gdb) p debug_rtx(op1) > (symbol_ref:SI ("a") <var_decl 0x7ffff6c2f900 a>) > $2 = void > > resulting in the ops array being populated as > (gdb) p n_ops > $3 = 3 > (gdb) p ops[0]@3 > $4 = {{op = 0x7ffff6d4b360, neg = 0}, {op = 0x7ffff6d483a8, neg = 0}, {op = 0x7ffff6c29490, neg = 0}} > (gdb) p debug_rtx(ops[0].op) > (reg:SI 0 ax [96]) > $5 = void > (gdb) p debug_rtx(ops[1].op) > (symbol_ref:SI ("a") <var_decl 0x7ffff6c2f900 a>) > $6 = void > (gdb) p debug_rtx(ops[2].op) > (const_int 1 [0x1]) > $7 = void > > Of note here is that the operands have been reordered from their > original positions. What was ax + 1 + sym is now ax + sym + 1, and it > happens that this ordering is correct in the sense that > simplify_plus_minus_op_data_cmp sorting of the ops array produces no > changes. Now any change made during sorting sets "canonicalized", so > I figure reordering while decomposing operands ought to set > "canonicalized" too. Indeed, the reordering seen above has > canonicalized the expression. (Of course the reordering during > decomposition might be exactly cancelled by later sorting, but it > hardly seems worth fixing that, and other cases where we might return > the input expression unchanged..) > > I'm still running bootstrap and regression tests on x86_64-linux, > this time with both -m64 and -m32 regression tests. > OK to apply assuming no regressions? > > PR rtl-optimization/63615 > * simplify-rtx.c (simplify_plus_minus): Set "canonicalized" on > decomposing PLUS or MINUS if operands are not placed adjacent > in the "ops" array. OK assuming no regressions. jeff
Index: gcc/simplify-rtx.c =================================================================== --- gcc/simplify-rtx.c (revision 216573) +++ gcc/simplify-rtx.c (working copy) @@ -4006,7 +4006,7 @@ ops[i].op = XEXP (this_op, 0); changed = 1; - canonicalized |= this_neg; + canonicalized |= this_neg || i != n_ops - 2; break; case NEG:
PR 63615 was caused by r21642 fixing the accounting of "n_constants" in simplify_plus_minus. Previously, any expression handled by simplify_plus_minus that expanded to more than two elements and contained at least one constant would have resulted in "n_constants" being larger than one, even if it had only one constant. This had the effect of setting "canonicalized" for such expressions. The missed optimisation had these operands to simplify_plus_minus: (gdb) p debug_rtx(op0) (plus:SI (reg:SI 0 ax [96]) (const_int 1 [0x1])) $1 = void (gdb) p debug_rtx(op1) (symbol_ref:SI ("a") <var_decl 0x7ffff6c2f900 a>) $2 = void resulting in the ops array being populated as (gdb) p n_ops $3 = 3 (gdb) p ops[0]@3 $4 = {{op = 0x7ffff6d4b360, neg = 0}, {op = 0x7ffff6d483a8, neg = 0}, {op = 0x7ffff6c29490, neg = 0}} (gdb) p debug_rtx(ops[0].op) (reg:SI 0 ax [96]) $5 = void (gdb) p debug_rtx(ops[1].op) (symbol_ref:SI ("a") <var_decl 0x7ffff6c2f900 a>) $6 = void (gdb) p debug_rtx(ops[2].op) (const_int 1 [0x1]) $7 = void Of note here is that the operands have been reordered from their original positions. What was ax + 1 + sym is now ax + sym + 1, and it happens that this ordering is correct in the sense that simplify_plus_minus_op_data_cmp sorting of the ops array produces no changes. Now any change made during sorting sets "canonicalized", so I figure reordering while decomposing operands ought to set "canonicalized" too. Indeed, the reordering seen above has canonicalized the expression. (Of course the reordering during decomposition might be exactly cancelled by later sorting, but it hardly seems worth fixing that, and other cases where we might return the input expression unchanged..) I'm still running bootstrap and regression tests on x86_64-linux, this time with both -m64 and -m32 regression tests. OK to apply assuming no regressions? PR rtl-optimization/63615 * simplify-rtx.c (simplify_plus_minus): Set "canonicalized" on decomposing PLUS or MINUS if operands are not placed adjacent in the "ops" array.