https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #7 from ktkachov at gcc dot gnu.org ---
Hmmm, digging through the reload and post-reload split dumps I noticed this
curiosity in arm.md:
(define_split
[(set (match_operand:DI 0 "s_register_operand" "")
(zero_extend:DI (match_operand 1 "nonimmediate_operand" "")))]
"TARGET_32BIT && reload_completed && !IS_VFP_REGNUM (REGNO (operands[0]))"
[(set (match_dup 0) (match_dup 1))]
{
rtx lo_part = gen_lowpart (SImode, operands[0]);
machine_mode src_mode = GET_MODE (operands[1]);
if (REG_P (operands[0])
&& !reg_overlap_mentioned_p (operands[0], operands[1]))
emit_clobber (operands[0]);
if (!REG_P (lo_part) || src_mode != SImode
|| !rtx_equal_p (lo_part, operands[1]))
{
if (src_mode == SImode)
emit_move_insn (lo_part, operands[1]);
else
emit_insn (gen_rtx_SET (lo_part,
gen_rtx_ZERO_EXTEND (SImode, operands[1])));
operands[1] = lo_part;
}
operands[0] = gen_highpart (SImode, operands[0]);
operands[1] = const0_rtx;
})
The instruction performs an emit_clobber, but the splitter is guarded on
reload_completed.
Does a clobber instruction even make any sense after reload?
Removing the reload_completed condition makes 'fixes' this test, but of course
then the !IS_VFP_REGNUM (REGNO (operands[0])) check is meaningless since before
reload we don't know what reg class operands[0] is assigned to, but that seems
to me to be the root cause.
