Re: forcing tail/sibling call optimization

[Richard Henderson <rth at redhat dot com>]

On Thu, Jan 04, 2001 at 07:24:14AM +1100, Fergus Henderson wrote:
> 	* tree.h (CALL_EXPR_FORCE_TAILCALL): New boolean field.

This part is fine.

> 	* expr.c (expand_expr): use expand_call_1 rather than expand_call,
> 	  passing CALL_EXPR_FORCE_TAILCALL field.

This should be completely unnecessary -- expand_call receives
the CALL_EXPR, from which it can read CALL_EXPR_FORCE_TAILCALL.

> 	* rtl.def (CALL_PLACEHOLDER): Add new boolean field force_tailcall.
> 	  integrate.c (copy_insn_list): Copy it.
> 	  sibcall.c (optimize_sibling_and_tail_recursive_call,
> 	  replace_call_placeholder) Use it.

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.

The later usage seems more in tune with the name of the
flag.  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.

Hmm.  I do suppose that would require that inlining be
disabled, or that it happen at the tree level.  But I'm
not sure what sort of evil inlining would imply for 
such functional languagaes as you are implementing.


r~