This is the mail archive of the
mailing list for the GCC project.
Re: Problems with sibling calls
- From: Ian Lance Taylor <iant at google dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 29 May 2009 07:53:53 -0700
- Subject: Re: Problems with sibling calls
- References: <4A1FB71D.email@example.com>
Georg-Johann Lay <firstname.lastname@example.org> writes:
> The trouble is this: If a callee gets some arguments passed on the
> stack or in call-saved regs, the callee is not ok for a sibling
> call. That's because sibcall_epilogue executes before sibcall insns.
I'm having trouble with your terminology "call-saved regs". Do that
mean "caller-saved regs" or "callee-saved regs"?
I gather that in the case where f wants to make a sibling call to g, the
problem is that this fails if g accepts arguments anywhere other than in
registers which are neither caller-saved nor callee-saved. I would
expect that that would be fairly easy to determine from the call
expression. You can be conservative when doing something odd like
passing a struct: the only effect would be that in an extremely small
number of cases gcc would make a regular call when it could make a
> Introduce a new backend hook
> bool targetm.function_ok_for_sibcall_with_cum (tree, tree,
> and call it with &args_so_far from calls.c:expand_call
It would be OK to change the existing hook to add a CUMULATIVE_ARGS*
parameter, but unfortunately you don't have the CUMULATIVE_ARGS at the
point where it is called. Adding another one does seem pretty ugly.