https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #390 from Kazumoto Kojima <kkojima at gcc dot gnu.org> --- (In reply to Richard Sandiford from comment #389) > (In reply to Oleg Endo from comment #304) > > (define_insn "block_lump_real" > > [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r")) > > (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r"))) > > (use (match_operand:SI 0 "arith_reg_operand" "r,r")) > > (use (match_operand 1 "" "Z,Ccl")) > > (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r")) > > > > (use (reg:SI R4_REG)) <<<<<< > > (use (reg:SI R5_REG)) <<<<<< > > (use (reg:SI R6_REG)) <<<<<< > > > > (clobber (match_dup 2)) > > (clobber (match_dup 3)) > > (clobber (match_dup 4)) > > (clobber (reg:SI PR_REG)) > > Sorry for the late reply, but I think this is somewhat dangerous, in that > the constraints (r) are more general than the predicates (sfunc_arg0_reg > etc.). > > Do we know why the pattern in trunk doesn't work? It looks correct to me, > and I think it should work with LRA too. Did Andrew P's patch (PR116058) > not help? Thanks for the comment! The patch in PR110658 has already been applied to our base repo devel/sh-lra. It doesn't fix this issue, though the symptom that clobber doesn't work as expected is very similar. As discussed in c#308 and c#309, it seems that LRA doesn't handle the clobber reg pattern if that reg is recognized as the input reg, unless it's call_insn. This observation is based on my vague understanding of LRA, though.
