[gclist] tail-calls in C/C++

Charles Fiterman cef@geode.geodesic.com
Tue, 06 Aug 1996 09:36:30 +0100


At 03:52 PM 8/5/96 -0700, you wrote:
>|   Sender: majordom@iecc.com (MajorDomo)
>|   Date: Mon, 05 Aug 1996 17:55:02 -0400
>|   From: Greg Morrisett <jgm@CS.Cornell.EDU>
>
>|   Why hasn't someone hacked gcc to do full tail-call elimination?
>|   With the Boehm-Weiser collector, this is really the only thing
>|   that's keeping me from generating very good C code from ML and
>|   Scheme.  
>
>I too would like to see this, but in general it would have to be
>enabled by a command-line option to the compiler because it
>effectively violates C semantics.
>
>The problem is the folloowing:
>
>	Assume A calls B which in turn tail-calls C
>	Either B uses ... or no prototype for B is visible at A.
>
>Thus A can call B with more arguments (and hence locations on the
>stack) than the number expected by B.
>
>Since B (in general) does not know how many arguments it was passed,
>it cannot in general pop its arguments from the stack.  That job is
>left to A which does so (lazily in some compilers) on return from B.
>
>Assume now that B calls C with more arguments than B thinks it got
>(e.g. B names X formal parameters but passes X+1 arguments to C).  B
>will have to "grow" the stack frame before calling C.

This obviously restricts where tail call optimization can be done.
It doesn't prevent all tail call optimization. It clearly doesn't
prevent tail recursion optimization for functions with a fixed
number of parms. These obviously have the right number of slots
on the stack.

Before being flamed for being off topic. This is actually germane
to conservative GC as it reduces the amount of stack to scan. So
are optimizations where the compiler zeros pointers that will
clearly never be used again. We might have a switch for gc optimized
code requested. In this a free or delete on a pointer which will
never be used again would zero that pointer. new could cooperate
with the collector where there are destructors removing the requirement
that users inherit from special classes like gcCleanup to register
destructors.

BTW is there a mailing list more germane to these topics.

Charles Fiterman	Geodesic Systems
Phone 312-728-7196	4745 N. Ravenswood
Fax   312-726-6096	Chicago Il 60015