https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |krebbel at gcc dot gnu.org,
| |stefansf at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(define_insn "*clrmem_short"
[(set (match_operand:BLK 0 "memory_operand" "=Q,Q,Q,Q")
(const_int 0))
(use (match_operand 1 "nonmemory_operand" "n,a,a,a"))
(use (match_operand 2 "immediate_operand" "X,R,X,X"))
(clobber (match_scratch:P 3 "=X,X,X,&a"))
(clobber (reg:CC CC_REGNUM))]
"(GET_MODE (operands[1]) == Pmode || GET_MODE (operands[1]) == VOIDmode)"
"#"
[(set_attr "type" "cs")
(set_attr "cpu_facility" "*,*,z10,cpu_zarch")])
operands[1] is a CONST_INT, so that feels like the first alternative, but the
first
CLOBBER is a REG rather than SCRATCH, so maybe during RA it was first the 4th
alternative and then a CONST_INT propagated to that?
If so, I wonder if all the
(clobber (scratch))
cases in all the s390.md define_split patterns shouldn't be instead either
(clobber (match_scratch 3))
or
(clobber (match_operand 3 "scratch_operand"))
so that they don't fail to split if it isn't SCRATCH but some REG (and just
ignore it in that case).
