https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930

--- Comment #12 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #10)
> Index: gcc/config/sh/sh.c
> ===================================================================
> --- gcc/config/sh/sh.c        (revision 225987)
> +++ gcc/config/sh/sh.c        (working copy)
> @@ -13888,6 +13888,7 @@
>        && !sh_insn_operands_modified_between_p (t_before_negc.insn,
>                                              t_before_negc.insn,
>                                              t_after_negc.insn)
> +      && !modified_between_p (get_t_reg_rtx (), curr_insn,
> t_after_negc.insn)
>        && !sh_unspec_insn_p (t_after_negc.insn)
>        && !volatile_insn_p (PATTERN (t_after_negc.insn))
>        && !side_effects_p (PATTERN (t_after_negc.insn))
> 
> I've added this code as part of PR 63986.  I've checked with make -k
> check-gcc RUNTESTFLAGS="sh.exp
> --target_board=sh-sim\{-m2a/-mb,-m4/-ml,-m4/-mb}" that there are no new SH
> specific fails, so I assume the patch above should be OK (although all the
> checks should probably be combined to avoid walking the insns repeatedly). 
> Could you please add it to your test run?

The toplevel "make -k check" on sh4-unknown-linux-gnu is running.
I'll report back when it completes.

BTW, during debugging the issue, I thought that this call-clobbered case
is excluded with sh_find_set_of_reg and found again that NONJUMP_INSN_P
is simply defined as (GET_CODE (X) == INSN).  Each time I've found it,
I've recalled that it isn't (GET_CODE (X) != JUMP_INSN), then the next
time...  Anyway I've tried another one liner

--- a/config/sh/sh-protos.h
+++ b/config/sh/sh-protos.h
@@ -198,7 +198,7 @@ sh_find_set_of_reg (rtx reg, rtx_insn* insn, F stepfunc,
     {
       if (BARRIER_P (result.insn))
        break;
-      if (!NONJUMP_INSN_P (result.insn))
+      if (!NONJUMP_INSN_P (result.insn) && !CALL_P (result.insn))
        continue;
       if (reg_set_p (reg, result.insn))
        {

and it works like as my expectation, though I'm not sure whether it's
a "right thing" or not.

Reply via email to