This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix 32-bit Sparc sibling call predicate
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "David S. Miller" <davem at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com, kukuk at suse dot de, rth at redhat dot com
- Date: Thu, 25 Apr 2002 01:15:05 -0400
- Subject: Re: Fix 32-bit Sparc sibling call predicate
- References: <20020424.093324.10150295.davem@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Apr 24, 2002 at 09:33:24AM -0700, David S. Miller wrote:
> 2002-04-24 David S. Miller <davem@redhat.com>
>
> PR target/6420
> * config/sparc/sparc.h (FUNCTION_OK_FOR_SIBCALL): Return false if
> 32-bit Sparc and current_function_returns_struct is true.
>
> Index: config/sparc/sparc.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/sparc/sparc.h,v
> retrieving revision 1.161.2.17
> diff -u -r1.161.2.17 sparc.h
> --- config/sparc/sparc.h 18 Apr 2002 23:34:11 -0000 1.161.2.17
> +++ config/sparc/sparc.h 24 Apr 2002 15:03:04 -0000
> @@ -1914,8 +1914,23 @@
> #define STRICT_ARGUMENT_NAMING TARGET_V9
>
> /* We do not allow sibling calls if -mflat, nor
> - we do not allow indirect calls to be optimized into sibling calls. */
> -#define FUNCTION_OK_FOR_SIBCALL(DECL) (DECL && ! TARGET_FLAT)
> + we do not allow indirect calls to be optimized into sibling calls.
> +
> + Also, on sparc 32-bit we cannot emit a sibling call when the
> + current function returns a structure. This is because the "unimp
> + after call" convention would cause the callee to return to the
> + wrong place. The generic code already disallows cases where the
> + function being called returns a structure.
> +
> + It may seem strange how this last case could occur. Usually there
> + is code after the call which jumps to epilogue code which dumps the
> + return value into the struct return area. That ought to invalidate
> + the sibling call right? Well, in the c++ case we can end up passing
> + the pointer to the struct return area to a constructor (which returns
> + void) and then nothing else happens. Such a sibling call would look
> + valid without the added check here. */
> +#define FUNCTION_OK_FOR_SIBCALL(DECL) \
> + (! TARGET_FLAT && (TARGET_ARCH64 || ! current_function_returns_struct))
Why have you dropped "DECL &&" ? That way you allow indirect calls to be
optimized into sibling calls, which I'm afraid sparc.c is not well
prepared to handle (it is doable, but it is not easy).
Jakub