This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: forcing tail/sibling call optimization

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]