This is the mail archive of the
mailing list for the GCC project.
Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
- From: Josh Conner <jconner at apple dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 21 Aug 2006 16:33:53 -0700
- Subject: Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
- References: <44EA29D7.email@example.com> <10608212253.AA25266@vlsi1.ultra.nyu.edu>
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.
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
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:
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:
struct S D.1105;
struct S D.1104;
D.1104 = foo ();
D.1105 = foo ();
bar (D.1104, D.1105) [tail call];
Note that we will get 4 instances of struct S generated on the stack:
two for D.110, 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