All -
I've been investigating the cause of pr25505, where the amount of stack
space being used for a particular C++ function went from <1K to ~20K
between gcc 3.3 and 4.0. One of the issues I ran into was that the
stack slot allocated to hold the result of a function returning a
structure was never being reused (see comment #5 in the PR for a simple
example).
The code in calls.c that allocates the location for storing the result
marks its address as being taken, which prevents it from being reused
for other function calls in the same scope:
/* For variable-sized objects, we must be called with a target
specified. If we were to allocate space on the stack here,
we would have no way of knowing when to free it. */
rtx d = assign_temp (TREE_TYPE (exp), 1, 1, 1);
mark_temp_addr_taken (d);
structure_value_addr = XEXP (d, 0);
target = 0;
So, my question is: is it really necessary to mark this location as
having its address taken? Yes, the address of the slot is passed to a
function, however I can't imagine any instances where the function
retaining that address after the call would be valid. Stepping through
the code with a debugger showed that the location is preserved until
after its value is copied out, so I don't believe that the value will
ever be overwritten too early.
In an effort to help understand whether this call was necessary, I ran
the test suite against 4.1 and mainline for both i686-pc-linux-gnu and
powerpc-apple-darwin8 (with all default languages enabled), but there
were no regressions. I also tried to track down the origins of this
code, but the original email discussions were somewhat nebulous. Here
is a link to the original patch:
http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00856.html
I also investigated where the other calls to mark_temp_addr_taken were
removed, which happened here:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00813.html
These appeared to me to be related to a patch that was introduced
shortly before which performed alias analysis on MEM locations (IIUC):
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00643.html
Before submitting a patch to remove this call, and the resultant dead
code, I thought I would see if anyone had some background knowledge as
to why this was present, and why I shouldn't remove it.
Thanks in advance for any advice.
- Josh
