Re: Problems with sibling calls

[Georg-Johann Lay <avr at gjlay dot de>]

Ian Lance Taylor schrieb:
> 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"?

They are callee-saved in that case.

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

Yes that's right. It would work if I recreate the information which code 
a couple of lines away did already, I just wanted to avoid doubling 
(some parts of) the code/work in order to keep the backend clean. 
Moreover, calls.c is far from being short and straight forward, and 
obviously many different cases must be handled. Many cases will 
disappear because the implementation is for a specific machine, though.

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

Yes, having two hooks that do almost the same is odd. The original 
TARGET_FUNCTION_OK_FOR_SIBCALL could always return true and the new one 
would be the worker instead. But that's definitely ugly. And the two 
hooks would need different default implementations (one returning false 
and the other true).

I am working with 4.3.3, and there args_fo_far is available when the 
hook gets called. The final call to FUNCTION_ARG with mode=VOIDmode will 
follow after the hook, which seems reasonable to me.

Georg-Johann