This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: forcing tail/sibling call optimization


>>>>> "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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]