https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100782
--- Comment #6 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Trying to understand why rejection happens: -fdump-rtl-all-slim 295r.reload
says:
Choosing alt 0 in insn 12: (0) =r (1) %0 (2) rI08
{*addsi3_compact_lra}
alt=0: No input/output reload -- refuse
...
12: r15:SI=r15:SI-0x4
I'm surprised the same (hard) reg is used in source and destination in insn 12.
*addsi3_compact_lra hints at special assumptions about it:
;; The *addsi3_compact is made an insn_and_split and accepts actually
;; impossible constraints to make LRA's register elimination work well on SH.
;; The problem is that LRA expects something like
;; (set rA (plus rB (const_int N)))
;; to work. We can do that, but we have to split out an additional reg-reg
;; copy or constant load before the actual add insn.
;; Use u constraint for that case to avoid the invalid value in the stack
;; pointer.
;; This also results in better code when LRA is not used. However, we have
;; to use different sets of patterns and the order of these patterns is
;; important.
;; In some cases the constant zero might end up in operands[2] of the
;; patterns. We have to accept that and convert it into a reg-reg move.
(define_insn_and_split "*addsi3_compact_lra"
[(set (match_operand:SI 0 "arith_reg_dest" "=r,&u")
(plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r")
(match_operand:SI 2 "arith_or_int_operand" "rI08,rn")))]
"TARGET_SH1 && sh_lra_p ()
&& (! reg_overlap_mentioned_p (operands[0], operands[1])
|| arith_operand (operands[2], SImode))"
"@
add %2,%0
#"
"&& reload_completed
&& ! reg_overlap_mentioned_p (operands[0], operands[1])"
[(set (match_dup 0) (match_dup 2))
(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 1)))]
{
/* Prefer 'mov r0,r1; add #imm8,r1' over 'mov #imm8,r1; add r0,r1' */
if (satisfies_constraint_I08 (operands[2]))
std::swap (operands[1], operands[2]);
}
[(set_attr "type" "arith")])
