native gdb.sum gdb.base/interrupt.exp
Richard Henderson
rth@redhat.com
Sat Aug 4 09:59:00 GMT 2001
On Fri, Aug 03, 2001 at 07:56:55PM +0200, Jan Hubicka wrote:
> > What if we attack the unaligned stack problem in main
> > by making main appear use alloca to align the frame?
> This sounds like good idea, modulo the pesimization of
> code in main. I am not sure how important it is except
> for trivial benchmarks.
I'm currently testing the following patch. I've reverted the
ix86_output_main_function_alignment_hack patch in advance in
hopes of getting a clean run out of the regression tester.
At -O0, we get
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
which is slightly silly, but not overmuch. With any optimization
things clean up as you'd hope.
r~
* config/i386/i386.h (FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN): New.
* function.c (expand_main_function): Implement it.
* doc/tm.texi: Document it.
Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.288
diff -u -p -r1.288 function.c
--- function.c 2001/08/01 18:03:28 1.288
+++ function.c 2001/08/04 16:49:09
@@ -6315,10 +6315,35 @@ mark_varargs ()
void
expand_main_function ()
{
-#if !defined (HAS_INIT_SECTION)
+#ifdef FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN
+ if (FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN)
+ {
+ int align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
+ rtx tmp;
+
+ /* Forcably align the stack. */
+#ifdef STACK_GROWS_DOWNWARD
+ tmp = expand_binop (Pmode, and_optab, stack_pointer_rtx,
+ GEN_INT (-align), stack_pointer_rtx, 1, OPTAB_WIDEN);
+#else
+ tmp = expand_binop (Pmode, add_optab, stack_pointer_rtx,
+ GEN_INT (align - 1), NULL_RTX, 1, OPTAB_WIDEN);
+ tmp = expand_binop (Pmode, and_optab, tmp, GEN_INT (-align),
+ stack_pointer_rtx, 1, OPTAB_WIDEN);
+#endif
+ if (tmp != stack_pointer_rtx)
+ emit_move_insn (stack_pointer_rtx, tmp);
+
+ /* Enlist allocate_dynamic_stack_space to pick up the pieces. */
+ tmp = force_reg (Pmode, const0_rtx);
+ allocate_dynamic_stack_space (tmp, NULL_RTX, BIGGEST_ALIGNMENT);
+ }
+#endif
+
+#ifndef HAS_INIT_SECTION
emit_library_call (gen_rtx_SYMBOL_REF (Pmode, NAME__MAIN), 0,
VOIDmode, 0);
-#endif /* not HAS_INIT_SECTION */
+#endif
}
extern struct obstack permanent_obstack;
Index: config/i386/i386.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.h,v
retrieving revision 1.195
diff -u -p -r1.195 i386.h
--- i386.h 2001/07/15 16:59:06 1.195
+++ i386.h 2001/08/04 16:49:11
@@ -640,6 +640,13 @@ extern int ix86_arch;
aligned; the compiler cannot rely on having this alignment. */
#define PREFERRED_STACK_BOUNDARY ix86_preferred_stack_boundary
+/* As of July 2001, many runtimes to not align the stack properly when
+ entering main. This causes expand_main_function to forcably align
+ the stack, which results in aligned frames for functions called from
+ main, though it does nothing for the alignment of main itself. */
+#define FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN \
+ (ix86_preferred_stack_boundary > STACK_BOUNDARY)
+
/* Allocation boundary for the code of a function. */
#define FUNCTION_BOUNDARY 16
Index: doc/tm.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.42
diff -u -p -r1.42 tm.texi
--- tm.texi 2001/08/04 01:31:41 1.42
+++ tm.texi 2001/08/04 16:49:15
@@ -1028,6 +1028,12 @@ for the desired alignment (measured in b
also defined, this macro must evaluate to a value equal to or larger
than @code{STACK_BOUNDARY}.
+@findex FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN
+@item FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN
+A C expression that evaluates true if @code{PREFERRED_STACK_BOUNDARY} is
+not guaranteed by the runtime and we should emit code to align the stack
+at the beginning of @code{main}.
+
@cindex @code{PUSH_ROUNDING}, interaction with @code{PREFERRED_STACK_BOUNDARY}
If @code{PUSH_ROUNDING} is not defined, the stack will always be aligned
to the specified boundary. If @code{PUSH_ROUNDING} is defined and specifies
More information about the Gcc-patches
mailing list