Re: forcing tail/sibling call optimization

[Fergus Henderson <fjh at cs dot mu dot oz dot au>]

I've finally gotten around to having another go at my patches which
allow the front-end to indicate to the back-end when it is safe to do
a tail call.

Firstly, I have a question about coding style.
Which of the following two alternative code samples attached is preferred?
The first one is more concise, but the code checking the list of reasons
for sibcall failure is duplicated.  The second is longer, but the
code dealing with each reason for sibcall failure is in a single place.

Secondly, I have some comments and a question in response to Richard's review
comments.  The semantics I would like for the flag are these:

	If CALL_EXPR_TAILCALL flag is set, this indicates that the
	call is in a tail position, and the caller's stack frame is
	no longer live.  The back-end shall report an error if the
	call is not in a tail position.  The back-end should trust
	the front-end about the liveness of the caller's stack
	frame; any use of the caller's stack frame after such a
	call is undefined behaviour.  The back-end will report a
	diagnostic if the call cannot be optimized as a tail call.

These semantics require the back-end to report an error if the front-end
marks a call as a tail call but the call is not in a tail position, which
requires keeping the CALL_PLACEHOLDER.  I think the error check is useful.
So I'd rather keep the CALL_PLACEHOLDER.  Is that OK?

> On 03-Jan-2001, Richard Henderson <rth@redhat.com> wrote:
> > I'm a bit confused by your intended usage here.  Are you
> > intending CALL_EXPR_FORCE_TAILCALL to indicate that it is
> > _possible_ to perform a tail call despite otherwise 
> > potential problems with the local stack frame?  Or are you
> > intending to indicate that this _will_ be a tail call.
> > In which case the change to CALL_PLACEHOLDER is 
> > not needed.  That is used to choose between alternate
> > code sequences at some later date.  If we _know_ that 
> > we are going to tail call, then we can simply generate
> > either the tail recursion or sibling call sequence 
> > directly and be done with it.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Attachment: sibcall-test1
Description: Text document

Attachment: sibcall-test2
Description: Text document