https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
oris 2,2,0 is a noop group_ending_nop.
Anyway, that oris 2,2,0 nor the li 28, 0 scheduling don't change anything and
I've
narrowed it down (- bad, + working) to the
--- cp/call.s 2023-11-27 14:24:12.616613833 +0000
+++ cp/call.s 2023-11-27 15:08:47.345457528 +0000
@@ -364,12 +364,13 @@ _ZL13splice_viableP11z_candidatebPb:
std 9,0(10)
mr 10,9
li 11,0
+ addi 10,10,96
li 7,1
addi 6,6,1
addi 12,12,1
ld 9,96(9)
std 9,0(8)
- std 11,96(10)
+ std 11,0(10)
stb 7,0(5)
ori 2,2,0
ld 9,0(8)
@@ -448,6 +449,7 @@ _ZL13splice_viableP11z_candidatebPb:
.cfi_restore 25
std 9,0(10)
mr 10,9
+ addi 10,10,96
li 26,0
li 28,0
ld 7,.LANCHOR0+136@toc@l(11)
@@ -459,7 +461,7 @@ _ZL13splice_viableP11z_candidatebPb:
li 11,0
li 7,1
std 9,0(8)
- std 11,96(10)
+ std 11,0(10)
stb 7,0(5)
ori 2,2,0
ld 9,0(8)
changes so far. So I bet 10 must be somewhere live after those stores.
Reverting further either the first or second two hunks breaks it again.
