Re: Altivec + 16 byte alignment

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> PREFERRED_STACK_BOUNDARY is a suggestion.  The theory is that
> *if* every object file is compiled with this, that we'll get
> some speedup at runtime, due to fewer misalignment fixups.
> 
> But it is *not* ABI mandated, and you have to assume that 
> someone somewhere may not honor this.

Yes, it is.  It's written in every runtime document that I have looked
at.  HP-UX doesn't perform misalignment fixups, although the linux port
does.  I guess you are saying that STACK_BOUNDARY really should be 512,
although I have the feeling that that's incompatible with the alignment
used for the outgoing argument block.  Can you describe under what
circumstances if any gcc will not be able to align to the preferred
stack boundary?

Looking at the documentation, it says that STACK_BOUNDARY should be set
to the *minimum* alignment enforced by hardware for the stack pointer
on the machine.  It doesn't say the ABI mandated value.  64-bit alignment
of the stack is sufficient for any type, except for lock semaphores.
If the PREFERRED_STACK_BOUNDARY doesn't break down, it might be
possible to set STACK_BOUNDARY to 32 (i.e., the same as PARM_BOUNDARY).

When STACK_BOUNDARY is set to 64, there is one fill word in the frame
as a result of the starting frame offset and the need to align it to a
STACK_BOUNDARY.  If STACK_BOUNDARY were set to 512, we would have 15
fill words.

> > Currently on the PA 32-bit ports, STACK_BOUNDARY
> > is 64 (same as BIGGEST_ALIGNMENT and PARM_BOUNDARY) but
> > PREFERRED_STACK_BOUNDARY is 512.  In part, this is because
> > we must define a non-zero STARTING_FRAME_OFFSET and the
> > start of the locals must lie on a STACK_BOUNDARY.
> 
> True, but it's also assumed that they lie on a PREFERRED_STACK_BOUNDARY,
> are they not?.  So I don't see that you're helping much?

I am certain that STARTING_FRAME_OFFSET must lie on a STACK_BOUNDARY.
Otherwise, you never get a zero frame in a leaf function.  I believe this
is because of the alignment specified in init_emit for STACK_POINTER_REGNUM.
This requirement is independent of any alignment requirement for locals.

PREFERRED_STACK_BOUNDARY sets the frame alignment and an upper limit on
the alignment used in assign_stack_local_1.  There doesn't seem to be a
similar limit in assign_stack_temp_for_type.  As far as I can tell,
STARTING_FRAME_OFFSET doesn't need to be a multiple PREFERRED_STACK_BOUNDARY.
The allocation code will simply pad to the alignment needed for the first
local.

PREFERRED_STACK_BOUNDARY is set to the alignment mandated by the ABI
for the stack pointer.  The 64-byte alignment of the frame was
mandated so that compilers could know when data structures allocated
on the stack are cache aligned.  However, we don't get much benefit
from this using GCC.

It would help if user code could align stack data on a cache line for
performance or other purposes.  I believe the patch that I sent early in
this thread, <http://gcc.gnu.org/ml/gcc/2003-02/msg00656.html>, allows
a user to do this.  It also allows using the low bits as tag bits, as
suggested by Fergus Henderson.  However, it doesn't provide the suggested
error checking.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)