Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?

[Josh Conner <jconner at apple dot com>]

Richard Kenner wrote:
>> 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.
> 
> Your tracing below confirms my recollection that I was the one who added that
> code.  Unfortunately, it came in as a merge from another tree, so it's going
> to be hard to do the archeology to figure out what it was added for, but the
> history certainly suggests to me that there *was* some test case when it did
> have a longer life and that's why it was added.  Remember that all this stuff
> is very sensitive to calling sequences so you may not be able to find it on
> one or two machines (e.g., try Sparc).  I suspect the test case involved
> something like two calls to the same function (that returns a structure)
> within the parameter list to a third function.
> 
> My strong suggestion is to leave this alone.  The benefits in terms of
> increased optimization opportunities is small and the costs if it
> *does* cause wrong code to be generated is large because we know it'll
> be an obscure and hard-to-find case.

Richard -

Thanks for looking at this and the advice.  I can understand the concern
about introducing a subtle bug for negligible benefit, although in my
case the benefit is somewhat more meaningful (~6k stack regained on a
single function).

Might you be able to provide any insight as to why you were able to
remove the other calls to mark_temp_addr_taken?  Was it indeed because
of improved alias analysis of MEM locations?  I wasn't, unfortunately,
able to derive this from the email traffic.  Here's the link again, in
case it's helpful:

  http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00813.html

I did investigate the case you described, where two function parameters
are calls to the same function returning a structure.  The front-end
generates temporaries to handle this, and so the middle-end-generated
temporaries are still restricted to a lifetime of a single statement.
Here's the tree dump:

baz ()
{
  struct S D.1105;
  struct S D.1104;

<bb 0>:
  D.1104 = foo ();
  D.1105 = foo ();
  bar (D.1104, D.1105) [tail call];
  return;

}

Note that we will get 4 instances of struct S generated on the stack:
two for D.110[45], and two more for holding the return values from the
two calls to foo.

Thanks again, and I appreciate any additional context you might be able
to offer.

- Josh