https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > I think there are 8 those peephole2s rather than just 4 (I've been looking
> > for
> > rtx_equal_p (XEXP.*, 0) in sync.md
>
> No, the other are not problematic.
Actually, you are right. Those other peephole2 sequences also write to the
memory and it is assumed, that the memory is not accessed outside the sequence.
Additional patch follows:
--cut here--
diff --git a/gcc/config/i386/sync.md b/gcc/config/i386/sync.md
index c7c508c8de8..c95cf50970e 100644
--- a/gcc/config/i386/sync.md
+++ b/gcc/config/i386/sync.md
@@ -231,7 +231,8 @@
"!TARGET_64BIT
&& peep2_reg_dead_p (2, operands[0])
&& rtx_equal_p (XEXP (operands[4], 0), XEXP (operands[2], 0))"
- [(set (match_dup 3) (match_dup 5))]
+ [(set (match_dup 3) (match_dup 5))
+ (set (match_dup 4) (match_dup 3))]
"operands[5] = gen_lowpart (DFmode, operands[1]);")
(define_peephole2
@@ -251,6 +252,7 @@
[(const_int 0)]
{
emit_move_insn (operands[3], gen_lowpart (DFmode, operands[1]));
+ emit_move_insn (operands[4], operands[3]);
emit_insn (gen_memory_blockage ());
DONE;
})
@@ -267,7 +269,8 @@
"!TARGET_64BIT
&& peep2_reg_dead_p (2, operands[0])
&& rtx_equal_p (XEXP (operands[4], 0), XEXP (operands[2], 0))"
- [(set (match_dup 3) (match_dup 5))]
+ [(set (match_dup 3) (match_dup 5))
+ (set (match_dup 4) (match_dup 3))]
"operands[5] = gen_lowpart (DFmode, operands[1]);")
(define_peephole2
@@ -287,6 +290,7 @@
[(const_int 0)]
{
emit_move_insn (operands[3], gen_lowpart (DFmode, operands[1]));
+ emit_move_insn (operands[4], operands[3]);
emit_insn (gen_memory_blockage ());
DONE;
})
--cut here--
