This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: tail call optimizations
- To: rearnsha at arm dot com
- Subject: Re: tail call optimizations
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 20 Mar 2000 10:38:48 -0700
- cc: Richard Henderson <rth at cygnus dot com>, gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <200003201213.MAA06246@cam-mail2.cambridge.arm.com>you write:
> 1) calls.c makes reference to md patterns sibcall, sibcall_value,
> sibcall_pop, sibcall_value_pop and sibcall_epilogue. Only the last of
> these has any documentation in md.texi. What do the others do? What form
> do they take?
They're just like normal calls in terms of arguments and such. I'll try to
crib up a patch to md.texi for this (I thought I had one, but apparently
not).
> 2) Can I assume that the compiler proper will not try to make a sibcall if
> the function might be passed the address of something in the current frame
> (eg address of a local variable, result of alloca())?
Correct. Though the detection of this could be significantly improved.
> 3) md.texi says
>
> "The @code{sibcall_epilogue} pattern must not clobber any arguments used
> for parameter passing or any stack slots for arguments passed to the
> current function."
>
> Maybe I've missed the point here, but how can I be sure that I won't do
> the latter? After all, the stack frame has to unwound by the epilogue
> instructions.
It removes the *current* function's frame, but the arguments were set up by
the caller into space allocated by the caller, so that's not a problem.
> PS. You, or was it Mark, said that some of the code would probably go
> when we moved to a tree-based implementation. Will that still work with
> tail-calling libcalls? (For that matter, does the current implementation
> work with libcalls?)
Not sure if it works with libcalls. Good question.
jeff