https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119980
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> 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))])
Possibly the following would fix it (not sure where to place the required
#include of alias.h)
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e170da3b0e6..3cfb54abbd0 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -28489,6 +28489,7 @@
"!MEM_VOLATILE_P (operands[1])
&& !MEM_VOLATILE_P (operands[2])
&& rtx_equal_p (operands[1], operands[2])
+ && mems_same_for_tbaa_p (operands[1], operands[2])
&& !reg_overlap_mentioned_p (operands[0], operands[2])"
[(set (match_dup 0) (match_dup 1))])
