This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Work in progress: "Super Sib Calls"; opinions sought
On Mon, Sep 09, 2002 at 03:12:18AM -0700, Richard Henderson wrote:
> On Mon, Sep 09, 2002 at 07:49:22PM +1000, Andreas Bauer wrote:
> > So, what I'm trying to do is offer a more general stack re-usage for calls
> > in tail position, even if the sib call optimisation fails. That is, I'm
> > generating RTL code similar to an ordinary call for each tail call, but
> > I'm moving the args back into the incoming arg space, _after_ they're all
> > evaluated and have been mangled via the outgoing arg space.
>
> Personally, I see this as the _easy_ part. This could be done
> within the existing framework for sibcalls. And, IMO, if you're
> not doing this within the existing framework for sibcalls you
> are making a mistake.
>
> The hard part is distinguishing
>
> void foo()
> {
> int x[100];
>
> // something local that uses x
>
> bar(); // legal to tail-call
> }
>
> void baz()
> {
> int x[100];
>
> global = x;
>
> bar(); // *not* legal to tail-call, since bar may reference x
> }
And also if we want to utilize the knowledge -fhosted gives about various
standard functions:
void foo(char *p)
{
char x[100];
char *q = strcpy (x, p);
// something local that uses q and x
bar(p);
}
void baz(char *p)
{
char x[100];
char *q = strcpy (x, p);
global = q + 10;
bar (p); // *not* legal to tail-call
}
void baz2(char *p)
{
char x[100];
char *q = strcpy (x, p);
bar (q); // *not* legal to tail-call, as q will
// (it is sufficient that it might though) contain a pointer
// to local stack area to be freed before tail call
}
etc., ie. unless you know everything about a particular external function,
you have to assume worst case it will store the pointers given to it into some
global variable, while for known functions you know that they will resp.
will not store them into global variables and know whether e.g. the return
value etc. might contain pointer derived from the one passed to it.
Jakub