This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: forcing tail/sibling call optimization
- From: Richard Henderson <rth at redhat dot com>
- To: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Cc: gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Mon, 16 Sep 2002 09:19:51 -0700
- Subject: Re: forcing tail/sibling call optimization
- References: <20001201185846.A12462@hg.cs.mu.oz.au> <200012012350.PAA08096@racerx.synopsys.com> <20010104072414.B7732@hg.cs.mu.oz.au> <20010103130916.C15036@redhat.com> <20010104095831.A23010@hg.cs.mu.oz.au> <20020915063041.GA29112@mars.cs.mu.oz.au>
On Sun, Sep 15, 2002 at 04:30:41PM +1000, Fergus Henderson wrote:
> 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.
I prefer the second. Alternately, something like
function_cannot_inline_p which returns a string with
the reason for failure.
> 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?
Yes, that's fine.
r~