https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119980
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Keywords| |needs-bisection Ever confirmed|0 |1 Last reconfirmed| |2025-04-29 Component|rtl-optimization |target Target| |x86_64-*-* CC| |jakub at gcc dot gnu.org, | |uros at gcc dot gnu.org Version|unknown |16.0 --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- Yes, it looks very very similar. In peephole2 the redundant load/store pair keeping the = 2 store data dependent on the later load vanishes (with -fdisable-rtl-combine, otherwise combine deletes it, see PR101641). Then sched2 comes along and breaks things. So, -fdisable-rtl-combine -fdisable-rtl-peephole2 fixes this. Let's keep this instance of the bug for the peephole2 bug. These kind of peepholes might not apply before scheduling at least - in reality after such patterns -fno-strict-aliasing should be enforced. ;; Attempt to optimize away memory stores of values the memory already ;; has. See PR79593. (define_peephole2 [(set (match_operand 0 "register_operand") (match_operand 1 "memory_operand")) (set (match_operand 2 "memory_operand") (match_dup 0))] "!MEM_VOLATILE_P (operands[1]) && !MEM_VOLATILE_P (operands[2]) && rtx_equal_p (operands[1], operands[2]) && !reg_overlap_mentioned_p (operands[0], operands[2])" [(set (match_dup 0) (match_dup 1))])