https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69008
Philip Blundell <pb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pb at gcc dot gnu.org
--- Comment #8 from Philip Blundell <pb at gcc dot gnu.org> ---
There seem to be a few different things going on here.
With the current state of master, I no longer get the redundant ldm using the
testcase from comment #7. But the store is still there:
.LFB1:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
add r3, sp, #8
stmdb r3, {r0, r1}
sub r3, r1, #1
add sp, sp, #8
add r0, r0, r3
@ sp needed
bx lr
A brief inspection of the rtl suggests that the way that we wrap multiple
stores in a PARALLEL might be preventing DSE from deleting the dead store. If
I hack arm.md to disable the define_expand "store_multiple" then the store goes
away:
.LFB1:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
sub r1, r1, #1
add sp, sp, #8
add r0, r0, r1
@ sp needed
bx lr
But we're still left with the useless stack pointer manipulation. As Andrew
said in comment #4, what seems to have happened here is that we reserve a stack
slot for the incoming args because they are BLKmode and, even though all the
memory accesses end up being deleted, the space in the stack frame is still
reserved and sp gets bumped to accommodate it.
The memory references to the stack frame have been eliminated before the
prologue and epilogue are generated so presumably it wouldn't be impossible to
detect that the frame is no longer actually needed at this point. But I don't
know how hard this would be to do in the general case.
