This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
- From: "olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 02 Jun 2015 21:00:47 +0000
- Subject: [Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
- Auto-submitted: auto-generated
- References: <bug-66358-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #3)
> (In reply to Oleg Endo from comment #2)
>
> Defaulting -mlra might be reasonable for gcc 6.
> For gcc 5, I thought the patch for prepare_move_operands like
>
> diff --git a/config/sh/sh.c b/config/sh/sh.c
> index 1cf6ed0..b855d70 100644
> --- a/config/sh/sh.c
> +++ b/config/sh/sh.c
> @@ -1789,9 +1789,8 @@ prepare_move_operands (rtx operands[], machine_mode
> mode)
> target/55212.
> We split possible load/store to two move insns via r0 so as to
> shorten R0 live range. It will make some codes worse but will
> - win on avarage for LRA. */
> - else if (sh_lra_p ()
> - && TARGET_SH1 && ! TARGET_SH2A
> + win on avarage. */
> + else if (TARGET_SH1 && ! TARGET_SH2A
> && (mode == QImode || mode == HImode)
> && ((REG_P (operands[0]) && MEM_P (operands[1]))
> || (REG_P (operands[1]) && MEM_P (operands[0]))))
>
> which would be a simplest form of the preallocating r0 for this limited case,
> though I'm afraid that it's still too invasive for the release branch.
There could be some negative side effects with the patch above, because it
forces the R0 usage quite early (at RTL expansion).
I'd like to give the RTL pass a try, although it's probably even more invasive
than the patch above.