https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kkojima at gcc dot gnu.org
--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> ---
This seems to be (indirectly) caused by the extra checks added to addsi3 as
part of PR 55212, in particular attachment 33707, and r218999, r219341.
Removing those with:
@@ -2129,11 +2129,6 @@
{
if (TARGET_SHMEDIA)
operands[1] = force_reg (SImode, operands[1]);
- else if (! arith_operand (operands[2], SImode))
- {
- if (reg_overlap_mentioned_p (operands[0], operands[1]))
- FAIL;
- }
})
(define_insn "addsi3_media"
@@ -2172,10 +2167,7 @@
[(set (match_operand:SI 0 "arith_reg_dest" "=r,&u")
(plus:SI (match_operand:SI 1 "arith_operand" "%0,r")
(match_operand:SI 2 "arith_or_int_operand" "rI08,rn")))]
- "TARGET_SH1
- && ((rtx_equal_p (operands[0], operands[1])
- && arith_operand (operands[2], SImode))
- || ! reg_overlap_mentioned_p (operands[0], operands[1]))"
+ "TARGET_SH1"
"@
add %2,%0
#"
@@ -2190,6 +2182,37 @@
}
[(set_attr "type" "arith")])
Removes the suspicious clrt-addc sequence. The added reg overlap
checks/restrictions also trigger some problems with ifcvt, because it tries to
emit insns that go like
(set (reg:SI 162)
(ne:SI (reg:SI 147 t)
(const_int 0 [0])))
(set (reg:SI 162)
(plus:SI (reg:SI 162) (const_int 2147483647)))
I haven't tested the patch above (with LRA enabled), but on CSiBE it does:
sum: 3347407 -> 3346163 -1244 / -0.037163 %
Kaz, do you have any memory of the extra checks? Isn't it enough to just
accept the addsi3 pattern as "rC = rA + {rB|imm}" and insert the reg-reg copy
after register allocation via split2, as it's already done? Why are the reg
overlap checks needed during matching of the patterns?
