Re: forcing tail/sibling call optimization

[Fergus Henderson <fjh@cs.mu.oz.au>]

On 26-Nov-2000, Per Bothner <per@bothner.com> wrote:
> I'm concerned that on many machines the default calling convention
> may make tail-call optimization difficult.  To make tail-call
> optimization practical (or at least efficient) you may want to use
> a non-default calling convention.

For compiling functional/logic languages to C, it's important to
get tail-call optimization, even if the code isn't efficient.

Making it efficient is desirable, of course, but I would like some
way to tell the C compiler to generate a tail call, even if this
is going to be slower than an ordinary call, so that we can get
O(1) stack space usage.

(I understand that implementing that in all possible cases is not
easy, that's why my specification defined it as a hint, with a warning
if the hint can't be applied.  However, in the long term it would be
nice if all the places where that warning is issued could be fixed
to instead generate appropriate code.)

> Specifically, the traditional C calling convention has the caller
> pop the arguments from the stack after the function returns.  This
> is needed to handle varags.  Safe and efficient tail-call
> elimination assumes the callee pops the arguments.
>
> This means that syntax associated with the call site is not enough.
>
> You also (or instead) need some annotation when the called function
> is compiled.

Providing alternative calling conventions which make tail calls
more efficient is a good idea.  However, I think the `__tailcall'
extension is useful even without it.  I think the two are separate
features, and I would like to add `__tailcall' support to GNU C
without waiting for appropriate alternative calling conventions to be
implemented.

Is that OK?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.