Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!mipos3!omepd!mcg From: mcg@mipon2.intel.com Newsgroups: gnu.gcc Subject: Re: Suggestions for improvements/enhancements to GCC Message-ID: Date: 28 May 89 01:10:08 GMT References: <4462@omepd.UUCP> <8641@phoenix.Princeton.EDU> Sender: news@omepd.UUCP Reply-To: mcg@mipon2.UUCP (Steven McGeady) Organization: Intel Corp., Hillsboro Lines: 27 In article <8641@phoenix.Princeton.EDU> haahr@princeton.edu (Paul Gluckauf Haahr) writes: >In article <4462@omepd.UUCP> mcg@mipon2.intel.com (Steven McGeady) writes: >> 2. Optimization Issues >> a. Support for leaf-procedure and tail-call optimizations >> Tail-calls are calls made immediately prior to a return. The call >> can often "piggy-back" on the current procedure's stack, and avoid >> the overhead of allocating another one. The crucial test is >> whether any of the called procedure's actual parameters are >> addresses on the calling procedure's frame. > >the conditions listed above are not sufficient. any reference to >an address in stack allocated memory that might store the address >(ie, passing it to a function or storing it in a global) is enough >to indicate that tail-call elimination is unsafe Mr. Haahr is correct in pointing out that it is very difficult to determine whether an actual parameter to a subroutine is an address on the local frame. Perhaps an indication of whether an operand's address is ever taken is the best that can be done. Better would be the combination of knowing an indication of whether any aliases for local frame addresses may have been created (e.g. frame_ever_addressed_p), and an indication that a particular parameter is known to hold a frame address. The latter may require dataflow analysis that may be beyond the capability of gcc. S. McGeady Intel Corp.