David Miller <da...@davemloft.net> writes:
> On targets such as sparc, where ARG_POINTER_REGNUM ==
> FRAME_POINTER_REGNUM, some of the invariants currently built into DSE
> simply do not hold.
>
> Unlike how DSE assumes, we will in fact see stores to frame pointer
> relative addresses for setting up outgoing arguments to a CALL.
>
> The result is that DSE can eliminate stores that setup those
> arguments.
>
> Two test cases and a DSE debugging dump for one of them can be found
> at:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684
>
> Richard and Kenneth, can you take a look at this? The patch is
> against the 4.7 branch, which is where I've been tracking this down.
> I'm currently running it through a regstrap and a glibc build (the
> latter of which is where I originally saw this problem)
This looks a little odd. ARG_POINTER_REGNUM is for incoming arguments
rather than outgoing arguments, so I don't see why it matters whether
it's the same as FRAME_POINTER_REGNUM.
I think the problem is in the way sparc.c:emit_soft_tfmode_libcall
reuses existing MEMs when passing arguments on the stack:
if (GET_CODE (this_arg) == MEM
&& ! force_stack_temp)
this_arg = XEXP (this_arg, 0);
-ffloat-store forces "a" and "b" to be stored in their argument slots,
and emit_soft_tfmode_libcall then passes the address of these incoming
argument slots to the libcall. But "a" and "b" don't escape, so DSE
thinks that the call can't read them.
Even after your change, I think the same thing could happen in cases
where -ffloat-store forces local variables rather than incoming
arguments to the stack, and where those local variables are then
passed as calls.
As you say, it works for 32-bit because that uses the normal
libcall code.
I think the DSE assuption is fair though. If you reuse MEMs like this,
then they're no longer just serving the purpose described by MEM_EXPR.
Richard
