new macro STARTING_FRAME_PHASE: alignment

[Geoff Keating]

> Date: Tue, 22 Jan 2002 15:33:19 +0100
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Cc: Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
>    geoffk@redhat.com, shebs@apple.com, dalej@apple.com
> 
> At 02:24 22.01.2002, Aldy Hernandez wrote:
> > > 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)
> >
> >much better.  now we don't need a macro at all.
> >
> >with this patch (below), hppa will be fixed as well.
> >
> >i'm testing this.  ok?
> >
> >2002-01-21  Aldy Hernandez  <aldyh@redhat.com>
> >
> >         * doc/tm.texi: Remove STARTING_FRAME_PHASE.
> >
> >         * config/rs6000/rs6000.h: Same.
> >
> >         * function.c (instantiate_virtual_regs): Remove
> >         STARTING_FRAME_PHASE.
> >         (assign_stack_local_1): Same.
> >         Calculate frame phase.
> 
> But what does this change anyway? This simple stripped down glibc testcase:
> 
> struct wait_node {
>      struct wait_node *next;       /* Next node in null terminated linked 
> list */
>      void * thr;            /* The thread waiting with this node */
>      int abandoned;                /* Atomic flag */
> } __attribute__ ((aligned(32)));


You're never going to get aligned(32) to work on the stack, as it is
only 16-byte aligned.  In fact, unless you say -maltivec, I believe
that GCC is told the stack is 8-byte aligned on most ppc platforms.

> struct wait_node * test (void)
> {
>    struct wait_node wn;
>    return &wn;
> }
> 
> still produces:
> 
>          .file   "test2.c"
>          .section        ".text"
>          .align 2
>          .globl test
>          .type   test,@function
> test:
>          stwu 1,-48(1)
>          addi 3,1,8
>          addi 1,1,48
>          blr
> .Lfe1:
>          .size   test,.Lfe1-test
>          .ident  "GCC: (GNU) 3.1 20020122 (experimental)"
> 
> With 32 byte alignment you can even see that there are 2 bugs here, &WN is 
> neither adjusted for the STACK_POINTER_OFFSET == 8, nor for the greater 
> than STACK_BOUNDARY object alignment.
> Wouldn't it be better to create a get_max_frame_align function analogous to 
> get_frame_size that could be used in the backend (eg. rs6000_stack_info)?

There is already such a variable.  However, it's bounded by
BIGGEST_ALIGNMENT among other things.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>