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
