This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: tail call optimizations
- To: law at cygnus dot com
- Subject: Re: tail call optimizations
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: 23 Mar 2000 00:41:46 -0800
- CC: gcc-patches at gcc dot gnu dot org
- References: <14543.953774670@upchuck>
Jeffrey A Law <law@cygnus.com> writes:
> In general, if a particular call might throw, then we can not perform
> tail call optimizations.
>
> Why? Because we'll have no way to know the proper return pointer since the
> callee returns directly to the parent of the caller. And without the proper
> return pointer, how are we supposed to know where to vector the exception?
This means that you can't do tail call optimisations when the tail
call is in a region where exceptions can be caught (in that
procedure), but in that case it's not really a 'tail call'.
Is there a problem I don't see where if you have
int foo () { bar(); }
and bar() throws, you can't just pass the exception up to foo's
caller, just as if foo's caller had called bar directly?
> I don't know if this is related to your problem, but it is the primary
> reason why (IMHO) tail calls optimizations are not particularly useful
> for C++.
I was going to say that there would be _fewer_ tail calls in C++, but
after a little thought I decided I couldn't be sure; because
destructors may very often be tail calls.
--
- Geoffrey Keating <geoffk@cygnus.com>