This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: forcing tail/sibling call optimization
- To: law at redhat dot com
- Subject: Re: forcing tail/sibling call optimization
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 27 Nov 2000 10:46:05 -0800
- Cc: dewar at gnat dot com, fjh at cs dot mu dot oz dot au, gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <20001126161445.8878634D82@nile.gnat.com><32243.975340713@upchuck>
>>>>> "Jeffrey" == Jeffrey A Law <law@redhat.com> writes:
Jeffrey> Instead of tagging the return itself, couldn't we use an
Jeffrey> attribute which would (in effect) tell the optimizer that
Jeffrey> any tail call in the function is safe to optimize? Yes,
Jeffrey> we lose the ability to specify that a specific call site
Jeffrey> is safe to optimize, but we don't have to invent yet
Jeffrey> another GCC extension of dubious value.
Yes. There is simply no need for an extension of this nature -- there
is no reason the compiler (perhaps with a few hints in the form of
attributes) can't do this optimization. Introducing this extension
would carry on a bad tradition in GCC: inventing extensions, rather
than having the compiler perform optimizations.
The issue, I take it, is that if there are addressed locals in the
caller, then the compiler might be afraid to do a tail call that would
clobber them? Since we're accepting the point of view that the
programmer is going to have to do something anyhow, it's worth
pointing out that the programmer can already make that clear to the
compiler: make the call after the addressed locals have gone out of
scope. In other words, instead of:
{
int i;
f(&i);
g(); /* I hope this will be a tail call! */
}
do:
{
{
int i;
f(&i);
}
g();
}
Yes, that's harder in some cases -- but it can always be done with a
goto to the call site, which can go in the outermost block of the
function.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com