Re: Work in progress: "Super Sib Calls"; opinions sought

[Richard Henderson <rth at redhat dot com>]

On Mon, Sep 09, 2002 at 12:51:55PM +1000, Andreas Bauer wrote:
> I'm treating super sib calls as an independend call sequence on the RTL
> level to not mess with the existing sibling call stuff.  But the
> technique I'm applying is very similar to what's already there in gcc.

Rather than wade through your patch, perhaps you can explain
_how_ you intend to attack the current problems with regular
sibcalls?

>  - super sib calls may have a positive stack frame

This isn't a problem at present.  What _is_ currently the
restriction is that the caller can't have local variables
whose address is taken.

The ideal restriction here is that the caller can't have
any local variables whose address is somehow leaked to
the callee.  But we currently don't do the data flow
analysis to find out what happens to the addreses we take.

I don't see how you can possibly address the problem posed
by the ideal restriction.

>  - super sib calls must not necessarily match in function signature

This also is not a restriction at present.  The restriction is that
the callee cannot use _more_ argument space than the caller did
(since this space is allocated by the caller's caller).

>  - super sib call arguments are not concerned by overlapping arguments

Better handling of this issue would be a good thing.

> This is achieved by creating "almost a normal call", but right before the
> actual call instruction would be used, I'm copying all the outgoing
> arguments back into the incoming argument space and jump to the subroutine
> instead.  The result is that I can reuse my incoming argument space and
> prevent stack growth for such cases.

How is this different from "normal" sibcalls?



r~