This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: forcing tail/sibling call optimization
On 03-Jan-2001, Richard Henderson <rth@redhat.com> wrote:
> Mostly what I meant here is "Does CALL_EXPR_TAILCALL imply tail-ness"?
I think the answer to that should be yes.
> CALL_EXPR_TAILCALL.
OK.
> if the front end didn't really care if the tail
> call didn't happen, it could query the target before setting the bit.
How can it query the target? The query needed is not just "does this
target support tail calls", it is "does this target support *this*
tail call", and the answer can depend on lots of stuff that the front
end doesn't want to know about.
> Let's just go with the one bit for now and make it mean "require".
I don't think that will work. The "require" bit is pretty useless
until GCC supports tail calls consistently, because AFAICT the
front-end can't safely set it, at least not without encoding too much
knowledge of the target and of GCC back-end limitations.
I'm happy to go with just one bit for now, but to be useful I think it
has to just mean "suggest" (to be specific: it is a guarantee from the
front-end to the back-end about liveness of locals and tail-ness, but
there should be no guarantee from the back-end that it will actually
use a tail call).
> So short-term I'd rather just disable rtl inlining if we
> expand a CALL_EXPR with CALL_EXPR_TAILCALL set.
OK, shall do.
--
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.