Re: new macro STARTING_FRAME_PHASE: alignment

[Geoff Keating <geoffk at geoffk dot org>]

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Tue, 22 Jan 2002 21:31:36 +0100
> Cc: Geoff Keating <geoffk@redhat.com>, aldyh@redhat.com,
>    gcc-patches@gcc.gnu.org, shebs@apple.com, dalej@apple.com
> 
> On Tuesday 22 January 2002 20:42, Richard Henderson wrote:
> > On Tue, Jan 22, 2002 at 08:39:22PM +0100, Franz Sirl wrote:
> > > But it is possible to get properly aligned objects on the stack if I use
> > > alloca, so why can't we make it work with automatic variables?
> >
> > Not 32-byte aligned you can't.  Well, theoretically possible, but
> > the alloca code doesn't handle it.
> 
> Hmm, I see. This means glibc threads are broken on PPC, cause AFAICS it 
> allocates a wait_node as an automatic variable, thus violating the alignment 
> rules for a lwarx/stwcx lock. I'm tempted to say that BIGGEST_ALIGNMENT is 
> wrong on PPC then (the gcc manual is a bit vague, "Biggest alignment that any 
> data type can require on this machine" doesn't strictly limit itself to ABI 
> defined types, the PPC "machine" needs a cache line aligned "type" for a 
> lock). The PPC ABI's should have required something like an atomic_t...

Actually, there are no alignment rules for locks (other than that they
must be aligned to word boundaries, like normal 'int' variables).  The
rule is that to be safe, two locks can't be in the same cache line.
This is achieved by making the size of a 'wait_node' large enough so
that two of them can't be allocated in the same cache line.

Of course, the biggest problem with this is that cache line size is a
property of the processor, not of the ISA, and so all this probably
breaks on IBM's POWER chips with a 64-byte cache line size.  However
the likelihood of a problem is very small, unless you start making
arrays of wait_nodes.

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