------- Comment #12 from vmakarov at redhat dot com 2010-09-01 18:06 -------
(In reply to comment #10)
> (insn 1407 1405 1406 78
> /mnt/b1/src/linux/set64/arch/x86/include/asm/cmpxchg_32.h:72 (set (reg:SI 2
> cx)
> (mem/c:SI (plus:SI (reg/f:SI 6 bp)
> (const_int -28 [0xffffffffffffffe4])) [0 S4 A32])) 47
> {*movsi_1} (nil))
>
> (insn 1406 1407 675 78
> /mnt/b1/src/linux/set64/arch/x86/include/asm/cmpxchg_32.h:72 (set (reg:SI 3
> bx)
> (reg:SI 2 cx [501])) 47 {*movsi_1} (nil))
>
> If insn 1406 came right before insn 1407, it would be still correct.
>
Yes, it would but I think the reload should still generate the right code in
this particular order of insns. IMHO, fixing the order of insn is not the
right thing to do because there might be situation of cycle (e.g. value of p600
is inherited from 2 but should be reloaded into 3 and p356 is inherited from 3
and should be reloaded into 2).
The problem is definitely in reload inheritance. Reg_last_reload_reg is not
invalidated by insn #1407 which is generated by another reload of insn #675.
Reload inheritence bug fixes result in either big code degradation or
possibility to induce new bugs. It could be ok to fix such problem on the
trunk but fixing it on release brach might be dangerous.
Looking through all patches for reload after gcc4.4 I don't think the bug is
fixed on the trunk (or in gcc 4.5). We probably are lucky that it did not
occur there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
