[gclist] tail-calls in C/C++
Henry G. Baker
hbaker@netcom.com
Tue, 6 Aug 1996 09:05:06 -0700 (PDT)
jgm@cs.cornell.edu:
> Why hasn't someone hacked gcc to do full tail-call elimination?
[snip]
> I've constructed an ML-to-C compiler using TIL/ML as the front-end
> and high-level optimizer. I'm currently using the Boehm-Weiser
> collector. I'd like to stick to standard C and
> standard C calling conventions in the generated code, ruling out
> Baker's Cheney-on-the-MTA, in order to maintain as much interoperability
> with legacy code (i.e., C and C++ libraries) as possible.
For what its worth, Cheney-on-the-MTA _does_ interoperate with legacy
code -- e.g., I/O calls, etc. -- so long as the legacy code doesn't
try to call back. (Even this will often work, but the rules become
more complex.)
> I'm already turning self-tail calls into C loops. I've also looked at
> integrating known, mutually recursive functions into a single large
> function, threaded by gotos. The only thing left to tackle are
> tail-calls to "unknown" functions -- i.e., code pointers imported from
> another module, or pulled out of a closure.
This particular set of optimizations is compatible with (orthogonal to?)
the Cheney-on-the-MTA stuff. You can aggregate mutually recursive functions
up to a certain size (to allow for separate compilation, e.g.), and then
start using Cheney-MTA/CPS for the 'foreign' functions.
> For many applications, this happens quite often. In particular, any
> code written in a continuation passing style has (by definition) lots
> of tail-calls to unknown functions.
Agreed.
> -Greg Morrisett
> jgm@cs.cornell.edu
--
Henry Baker
www/ftp directory:
ftp.netcom.com:/pub/hb/hbaker/home.html