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

Reply via email to