This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] MUST_PASS_IN_STACK for SPARC
- To: gcc-patches at egcs dot cygnus dot com
- Subject: [PATCH] MUST_PASS_IN_STACK for SPARC
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 2 Dec 1999 15:27:43 +0100
Hi!
What's the reason why the default MUST_PASS_IN_STACK includes structures
padded on the wrong side?
On SPARC, MUST_PASS_IN_STACK cannot be defined at least for the usage in
function.c, because the ABI sais structures up to 16 bytes are promoted into
registers, so e.g. SunPRO generated code calling gcc generated code would
pass the structure in registers and gcc code would read it from the stack
where it is not. I've checked with this patch several different structure
layouts and they seem to be computed correctly, albeit inefficiently (but
without defining this in sparc.h it is much more inefficient and in some
cases produces bad code (and as mentioned above does not apply with the
ABI)). gcc does not e.g. optimize out stores which were generated to
virtual_stack_vars_rtx, eventhough it just stores into those places and
nobody reads it ever.
1999-12-02 Jakub Jelinek <jakub@redhat.com>
* config/sparc/sparc.h (MUST_PASS_IN_STACK): New macro.
--- config/sparc/sparc.h.jj Wed Dec 1 10:22:20 1999
+++ config/sparc/sparc.h Thu Dec 2 15:07:19 1999
@@ -1765,6 +1765,13 @@ init_cumulative_args (& (CUM), (FNTYPE),
#define FUNCTION_ARG_ADVANCE(CUM, MODE, TYPE, NAMED) \
function_arg_advance (& (CUM), (MODE), (TYPE), (NAMED))
+/* Nonzero if we do not know how to pass TYPE solely in registers. */
+
+#define MUST_PASS_IN_STACK(MODE,TYPE) \
+ ((TYPE) != 0 \
+ && (TREE_CODE (TYPE_SIZE (TYPE)) != INTEGER_CST \
+ || TREE_ADDRESSABLE (TYPE)))
+
/* Determine where to put an argument to a function.
Value is zero to push the argument on the stack,
or a hard register in which to store the argument.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.18 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________