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

[Richard Henderson <rth at redhat dot com>]

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
	}

> However, in cases where the callee requires as much
> (or less) arg space as the caller, super sib calls actually optimise the
> call, _even_ if the current function has allocated huge amounts of stack
> space (for locals).  Note that sibcalls currently fail in such cases!

For *exactly* the reason above!  You absolutely positively *must*
guarantee that no stack frame addresses escape from the function.
We don't currently do that, and thus

              /* ??? Overly conservative.  */
              || frame_offset

simply notes that if there is no local stack frame, none of it
could have possibly escaped.  (My previous message was confused on
this issue -- I thought we did minimal scanning; apparently we do
nothing at all.)

If you do not plan to address this data flow issue in some way,
you might as well quit now.



r~