https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In this particular case it is the sync.md:398 peephole2:
(define_peephole2
[(set (match_operand:DF 0 "memory_operand")
(match_operand:DF 1 "any_fp_register_operand"))
(set (mem:BLK (scratch:SI))
(unspec:BLK [(mem:BLK (scratch:SI))] UNSPEC_MEMORY_BLOCKAGE))
(set (match_operand:DF 2 "fp_register_operand")
(unspec:DF [(match_operand:DI 3 "memory_operand")]
UNSPEC_FILD_ATOMIC))
(set (match_operand:DI 4 "memory_operand")
(unspec:DI [(match_dup 2)]
UNSPEC_FIST_ATOMIC))]
"!TARGET_64BIT
&& peep2_reg_dead_p (4, operands[2])
&& rtx_equal_p (XEXP (operands[0], 0), XEXP (operands[3], 0))"
[(const_int 0)]
{
emit_insn (gen_memory_blockage ());
emit_move_insn (gen_lowpart (DFmode, operands[4]), operands[1]);
DONE;
})
that triggers here but from what I can read, all the r7-1112 peephole2s
optimize away stores to some memory on the assumption that the memory is read
only once (in another insn matched by the same peephole2).
I'm not 100% sure if we can rely for it on spill slots for which r7-112 seems
to have been written, but for other memory we'd need to prove that the memory
is dead.
Rather than removing those peephole2s altogether, I wonder if we just shouldn't
check that the memory_operand which we'd optimize away stores to aren't spill
slots.
