This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: new macro STARTING_FRAME_PHASE: alignment
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Richard Henderson <rth at redhat dot com>, Aldy Hernandez <aldyh at redhat dot com>, gcc-patches at gcc dot gnu dot org, geoffk at redhat dot com, shebs at apple dot com, dalej at apple dot com
- Date: Tue, 22 Jan 2002 11:51:49 +1030
- Subject: Re: new macro STARTING_FRAME_PHASE: alignment
- References: <20020119023540.GA2533@redhat.com> <20020121160054.P19335@redhat.com>
On Mon, Jan 21, 2002 at 04:00:54PM -0800, Richard Henderson wrote:
> On Fri, Jan 18, 2002 at 06:35:40PM -0800, Aldy Hernandez wrote:
> > this patch introduces a new macro STARTING_FRAME_PHASE (documented).
>
> There is no need for a new macro. The frame pointer _must_ be
> aligned, as we assert here:
>
> emit-rtl.c:4719: REGNO_POINTER_ALIGN (FRAME_POINTER_REGNUM) = STACK_BOUNDARY;
>
> therefore it must always be the case that
>
> sb = STACK_BOUNDARY / BITS_PER_UNIT;
> off = STARTING_FRAME_OFFSET % sb;
>
> STARTING_FRAME_PHASE == (off ? sb - off : 0)
See http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00954.html, which is
very similar to Aldy's patch.
+@item ALIGN_STARTING_FRAME
+If defined, local variable stack slots will first have this value added
+to the offset before calculating address alignment padding. This is
+useful when STARTING_FRAME_OFFSET is not a multiple of BIGGEST_ALIGNMENT
+or PREFERRED_STACK_BOUNDARY.
hppa32 wants STACK_BOUNDARY == 64, PREFERRED_STACK_BOUNDARY == 128,
BIGGEST_ALIGNMENT == 128. Your calculation doesn't quite work for
this case, but may if you replace STACK_BOUNDARY with
PREFERRED_STACK_BOUNDARY. That might be a bit much though, hence
there is a reasonable need for another macro.
--
Alan Modra
IBM OzLabs - Linux Technology Centre