This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Jeff Law <law at redhat dot com>*To*: gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>*Date*: Fri, 24 Oct 2014 13:36:38 -0600*Subject*: Re: Fix 63615 - FAIL: gcc.target/i386/addr-sel-1.c*Authentication-results*: sourceware.org; auth=none*References*: <20140905013004 dot GN17693 at bubble dot grove dot modra dot org> <20140909115027 dot GR17693 at bubble dot grove dot modra dot org> <CAFiYyc1va8=f280dSu6VPkGxQ4=Sixf5q1rx4Hzgte0i08Qmxw at mail dot gmail dot com> <20140909143050 dot GU17454 at tucnak dot redhat dot com> <CAFiYyc29Pa9wUvxWc0iEFTaRq4tDSRuLRY3_pE18=6u6quArYA at mail dot gmail dot com> <20140910021629 dot GS17693 at bubble dot grove dot modra dot org> <20141016065557 dot GJ4267 at bubble dot grove dot modra dot org> <20141016070758 dot GF10376 at tucnak dot redhat dot com> <20141020104656 dot GU4267 at bubble dot grove dot modra dot org> <20141020105523 dot GL10376 at tucnak dot redhat dot com> <20141023065643 dot GF4267 at bubble dot grove dot modra dot org>

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

**References**:**Re: PR debug/60655, debug loc expressions***From:*Alan Modra

**Re: PR debug/60655, debug loc expressions***From:*Jakub Jelinek

**Re: PR debug/60655, debug loc expressions***From:*Alan Modra

**Re: PR debug/60655, debug loc expressions***From:*Jakub Jelinek

**Fix 63615 - FAIL: gcc.target/i386/addr-sel-1.c***From:*Alan Modra

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |