This is the mail archive of the
mailing list for the GCC project.
Re: forcing tail/sibling call optimization
- To: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Subject: Re: forcing tail/sibling call optimization
- From: Richard Henderson <rth at redhat dot com>
- Date: Wed, 3 Jan 2001 13:09:16 -0800
- Cc: gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <20001201185846.A12462@hg.cs.mu.oz.au> <200012012350.PAA08096@racerx.synopsys.com> <20010104072414.B7732@hg.cs.mu.oz.au>
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.