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]

[PATCH/RFC] ARM -- Implement ATPCS stack alignment rules

This is another patch that originates from Richard Earnshaw, and
that has been in-use in NetBSD's 2.95.3-based compiler for some time.

It implements the ATPCS stack alignment rules, which is to say, the stack
must always by aligned to an 8-byte boundary on entry to a function call
(and thus non-leaf functions must have stack frames which are multiples
of 8 bytes).

I'm not asking for approval of the patch yet, because I have more testing
to do (I've tested it with arm-elf sim, with no regressions, to make sure
the non-ATPCS case is not broken, but have not yet actually tested the
ATPCS case, and the function prologue/epilogue code in 3.3 is quite a bit
different than in 2.95.3), and there are some things I'm unsure about, and
would like to get some feedback on.

First of all, note that since arm_get_frame_size() always returns a rounded
size, some uses of the ROUND_UP() macro were eliminated.

Also, the new arm_get_frame_size() function always rounds to at least a
4-byte boundary.  The diff will show that there are some parts of the code
which were using get_frame_size() in an unprotected fashion (that is, not
4-byte-rounded).  These places are:

	- use_return_insn: This one should be no problem, because the
	  test was really just for "was there a stack frame".

	- arm_output_epilogue: This one actually used the raw frame
	  size from get_frame_size to generate an add insn to pop the
	  stack.  As I understand it, get_frame_size() isn't guaranteed
	  to return a value that is rounded to STACK_BOUNDARY, so this
	  one definitely needs to be sanity-checked.  Does the old code
	  actually have a bug?

	- arm_expand_prologue: This also used the output of get_frame_size()
	  to generate a value directly used in a stack-adjusting insn.

	- thumb_expand_prologue: This takes the raw size from
	  get_frame_size and then applies ROUND_UP() to it later.  I guess
	  I can now eliminate the ROUND_UP() of the value.  A sanity-check
	  here is also appreciated.

	- thumb_expand_epilogue: This is the same situation is
	  thumb_expand_prologue.  Same question applies :-)

Also, there's an "XXXJRT" in arm_get_frame_size() that should be
checked -- basically, I'm wondering if we can skip checking for FPA

Anyway, to test, I'm going to enable TARGET_ATPCS in the arm-elf config
and run the testsuite with the arm-elf sim.

	* config/arm/arm-protos.h (arm_get_frame_size): New prototype.
	* config/arm/arm.c (arm_get_frame_size): New function.
	(use_return_insn, arm_output_epilogue, arm_output_function_epilogue)
	(arm_compute_initial_elimination_offset, arm_expand_prologue)
	(thumb_expand_prologue, thumb_expand_epilogue): Use arm_get_frame_size.
	* config/arm/arm.h (PREFERRED_STACK_BOUNDARY): Define.
	(THUMB_INITIAL_ELIMINATION_OFFSET): Use arm_get_frame_size.

        -- Jason R. Thorpe <>

Attachment: arm-stack-patch
Description: Text document

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