Re: Problems with sibling calls

[Ian Lance Taylor <iant at google dot com>]

Georg-Johann Lay <avr@gjlay.de> 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
sibling call.

> Introduce a new backend hook
>    bool targetm.function_ok_for_sibcall_with_cum (tree, tree,
> CUMULATIVE_ARGS*);
> 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.

Ian