On 6/26/24 7:27 PM, Oleg Endo wrote:
On Wed, 2024-06-26 at 18:30 -0600, Jeff Law wrote:
OK, then what's the default config of your test setup / triplet?
Can you please show the generated code that you get? Because - like I said
- I can't reproduce it.
test01:
sts.l pr,@-r15 ! 31 [c=4 l=2] movsi_i/10
add #-4,r15 ! 32 [c=4 l=2] *addsi3/0
mov.l .L3,r0 ! 26 [c=10 l=2] movsi_i/0
jsr @r0 ! 12 [c=5 l=2] call_valuei
mov.l r6,@r15 ! 4 [c=4 l=2] movsi_i/8
mov.l @r15,r1 ! 29 [c=1 l=2] movsi_i/5
add r1,r0 ! 30 [c=4 l=2] *addsi3/0
add #4,r15 ! 36 [c=4 l=2] *addsi3/0
lds.l @r15+,pr ! 38 [c=1 l=2] movsi_i/14
rts
nop ! 40 [c=0 l=4] *return_i
Note that there's a scheduling barrier in the RTL between insns 30 and
36. So instructions prior to insn 36 can't be used to fill the delay slot.
Thanks. Now I'm also seeing the same result. Needed to specify -O2 to get
that. -O1 was not enough it seems.
I don't know why you said that the code for this case improved -- it has
not?!
I think the test is still valid. The reason for the failure might be
different from the original one (the scheduling barrier for whatever
reason), but the end result is the same -- the last delay slot is not
stuffed, although the 'add r1,r0' could go in there.
I'd like to revert the removal of this test case, as it catches a valid
issue.
Before the IRA patch there is an additional prologue/epilogue
save/restore for a callee saved register. That's what filled the delay
slot before.
THe add r1,r0 can not move down to fill the delay slot. There's
scheduling barrier in the RTL.
Feel free to restore it, but you're just adding a bogus, failing, test
to the testsuite.
jeff
