Steven Bosscher <[EMAIL PROTECTED]> writes:
> On Sunday 26 February 2006 14:23, Kenneth Zadeck wrote:
>> Did richard's untested patch not fix this?
>
> No. That patch only makes postreload not emit those reg-reg moves,
> but it does not prevent reload from producing the redundant insns in
> the first place. So that patch just papers over the problem we seem
> to have in reload.
Right. The idea of that patch was just to improve the no-op killing
in postreload so that it would get rid of no-op moves that postreload
creates itself. Since the no-op moves that Steven was seeing seemed to
come from reload, I thought it might be an alternative to checking for
no-op moves in every DCE pass.
It sounds like the patch does get rid of the nops, so I guess I'll
bootstrap it and submit it.
As far as Steven's example goes, the reason is related to:
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00661.html
(long post, sorry). The instructions before reload are:
(insn 45 43 47 6 (set (reg:SI 62 [ D.1602 ])
(reg:SI 63 [ ivtmp.46 ])) 34 {*movsi_1} (nil)
(nil))
(insn 47 45 48 6 (set (reg/f:SI 73)
(mem/s/f/j:SI (plus:SI (reg:SI 63 [ ivtmp.46 ])
(const_int -4 [0xfffffffc])) [0 <variable>.rtvec S4 A8])) 34 {*m
ovsi_1} (nil)
(expr_list:REG_EQUIV (mem/s/f/j:SI (plus:SI (reg:SI 63 [ ivtmp.46 ])
(const_int -4 [0xfffffffc])) [0 <variable>.rtvec S4 A8])
(nil)))
Register 63 is spilled to the stack and register 62 is allocated to esi.
Thus the first insn is reloaded as "esi := slot(63)". The second needs
an input reload for reg 63, and tries to use inheritance. There are
no previous reloads of this value to inherit (insn 45 didn't need any
reloads), so the inheritance code uses find_equiv_reg instead.
This matches:
But as the (b)->(a) results show, most of the benefit of the current
code comes from cases where we can't inherit the reload. In fact the
typical situation seems to very much like the one that's causing trouble.
We have sequences like:
(set (reg:SI R2) (reg:SI R1))
...
(set (reg:SI R3) (... (reg:SI R2) ...))
where, as above, R1 is allocated a hard register G1 and R2 is spilled
to the stack. We again choose to use G1 for the input reload in the
second instruction, at first thinking that we can inherit the value
from the first insn. This doesn't happen, so we end up with a reload:
(set (reg:SI R2) (reg:SI G1))
...
(set (reg:SI G1) (reg:SI R2)) <----
(set (reg:SI R3) (... (reg:SI G1) ...))
but the post-reload optimisers can remove it.
This clearly isn't as it should be, of course.
Richard
