This is the mail archive of the gcc-patches@gcc.gnu.org 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: PATCH for sibcalls on i386

From: Richard Henderson <rth at redhat dot com>
To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
Cc: Hans-Peter Nilsson <hp at bitrange dot com>, gcc-patches at gcc dot gnu dot org
Date: Mon, 30 Sep 2002 17:05:56 -0700
Subject: Re: PATCH for sibcalls on i386
References: <Pine.BSF.4.44.0209301623490.37307-100000@dair.pair.com> <200209302107.g8UL7wAP024638@hiauly1.hia.nrc.ca>

On Mon, Sep 30, 2002 at 05:07:58PM -0400, John David Anglin wrote:
> I've been looking and I don't have a full explanation yet.  I see in
> expand call that try_tail_call is 0 and try_tail_recursion is 1.  It
> looks like try_tail_call == 1 is necessary for sibcall generation
> (see line 2623 in calls.c).  try_tail_call is 0 because
> FUNCTION_OK_FOR_SIBCALL always is 0 for TARGET_64BIT.  What I don't
> understand is why we get a sibcall on hppa-linux which defines
> FUNCTION_OK_FOR_SIBCALL to be 0.

Do you get a sibcall?  try_tail_recursion does not rely on
the sibcall machinery, and is independent of it.  It should
not be shut off by FUNCTION_OK_FOR_SIBCALL.


r~

Follow-Ups:
- Re: PATCH for sibcalls on i386
  - From: John David Anglin

References:
- Re: PATCH for sibcalls on i386
  - From: Hans-Peter Nilsson
- Re: PATCH for sibcalls on i386
  - From: John David Anglin

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