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))])
