This is the mail archive of the
mailing list for the GCC project.
Re: forcing tail/sibling call optimization
Mark Mitchell <firstname.lastname@example.org> writes:
> >>>>> "Andi" == Andi Kleen <email@example.com> writes:
> Andi> Problem I see with that is diagnostics again: e.g. someone
> Andi> depends on a particular call being a tail call and not
> Andi> allocating new storage.
> The ANSI/ISO C way of doing this would be a #pragma (or _Pragma) near
> the call site. In GCC, we could do that, or we could do something
> __tailcall__ (xyz (foo));
> or something. But that magic should be only used for warnings -- it
> should not be used to have the compiler generate different code.
Not only should it not be used for generating different code, it
*cannot* be used for generating different code.
The caller of xyz (call it f) would have to jump to xyz. The caller
of f is going to pop f's args when f returns. How is the caller going
to pop off the right amount of space after f's effectively changed the
amount of space that it's using? If xyz uses the same amount of stack
space as f, then it's possible. The nature of the specific
instructions used for manipulating the stack could make it possible.
But I don't see how it can work in general.