reorg bug + patch
Jeffrey A Law
law@cygnus.com
Wed Jan 12 02:34:00 GMT 2000
In message < 200001061056.CAA01708@netcom.com >you write:
> The problem occurs on targets with a delayed branch instruction
> and an addressing mode with side effects (e.g. postinc, etc), such
> as the Hitachi SH.
There's a few targets this can potentially effect. Luckily the code in
question isn't triggered all that often (which probably explains why you've
been the only folks to have problems with it).
> Here is a dump of the rtx just prior to the delayed branch filling pass:
[ ... ]
> (insn 4919 4541 4916 (parallel[
> (set (reg:SF 24 fr0)
> (mem/s:SF (post_inc:SI (reg:SI 2 r2)))) <- look here
> (use (reg/v:PSI 48 fpscr))
> (clobber (scratch:SI))
> ] ) 157 {movsf_ie} (nil)
> (nil))
Per our earlier discussion reload needs to attach a REG_INC note to this
insn and should be doing so in the current development sources. Right?
> The culprit appears to be this chunk of code in reorg.c:
>
> /* If this insn is a register-register copy and the next insn has
> a use of our destination, change it to use our source. That way,
> it will become a candidate for our delay slot the next time
> through this loop. This case occurs commonly in loops that
> scan a list.
Yup.
> Anyway, here is my first patch to fix the first problem:
>
> Jan 6 02:14:33 PST 2000 Toshiyasu Morita (toshi.morita@sega.com)
>
> * reorg.c (fill_slots_from_thread): Actually check modified_in_p()
> before replacing rtx.
The comment isn't actually useful. reorg runs long after regmove, so the
code in reorg should not effect address inheritance in any way shape or form.
> *************** fill_slots_from_thread (insn, condition,
> *** 3729,3734 ****
> --- 3732,3738 ----
> && ! reg_set_p (SET_DEST (pat), next)
> && ! reg_set_p (SET_SRC (pat), next)
> && reg_referenced_p (SET_DEST (pat), PATTERN (next))
> + && ! modified_in_p (SET_DEST (pat), next))
> validate_replace_rtx (SET_DEST (pat), SET_SRC (pat), next);
I'm not sure how you made this diff since the reg_referenced_p line should
have had another close paren in the original sources. Anyway, I added the
call to modified_in_p to this code in the development sources by hand.
Thanks,
jeff
More information about the Gcc-patches
mailing list