http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-03-25
CC| |bernds at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-03-25
13:46:43 UTC ---
FWIW, the problem is AFAICT still present in mainline, but it is latent, for
the testcase no longer triggers the problem that 4.6 did. The only change I
could find to relevant portions of the reload code was the fix for bug 47976,
but it doesn't seem to fix this particular issue. Regardless, maybe Bernd can
offer some guidance since he's the reload expert ;-)
In GCC 4.6 r185770, the reloads for insn 288 are:
Reloads for insn # 288
Reload 0: reload_in (SI) = (post_inc:SI (reg:SI 145 [ ivtmp.76 ]))
reload_out (SI) = (post_inc:SI (reg:SI 145 [ ivtmp.76 ]))
ADDR_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), inc by 4
reload_in_reg: (post_inc:SI (reg:SI 145 [ ivtmp.76 ]))
reload_reg_rtx: (reg:SI 9 %a1)
Reload 1: reload_out (SI) = (reg/f:SI 124 [ D.1788 ])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (reg/f:SI 124 [ D.1788 ])
Reload 2: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5
MEM[base: D.1889_285, offset: 0B]+0 S4 A16])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5
MEM[base: D.1889_285, offset: 0B]+0 S4 A16])
in GCC trunk r185451, the same insn is numbered 296, and it has a single
reload, for both pseudos already got REGs:
Reload 0: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 9 %a1 [orig:110
ivtmp.82 ] [110])) [4 MEM[base: D.1990_299, offset: 0B]+0 S4 A16])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 9 %a1 [orig:110 ivtmp.82
] [110])) [4 MEM[base: D.1990_299, offset: 0B]+0 S4 A16])