Altivec + 16 byte alignment

[Richard Henderson]

On Wed, Feb 12, 2003 at 05:31:20PM -0500, John David Anglin wrote:
> You mean STACK_BOUNDARY?

Yes, sorry.

> > There are passes in gcc, particularly combine, that look
> > at the advertised alignment for a pointer and know that
> > the low bits are zero, and perform optimizations based on
> > this.  If the alignment doesn't exist, the optimizations
> > produce incorrect results.
> 
> I assume that it's actually the value specified by
> PREFERRED_STACK_BOUNDARY stack boundary that is used for
> the above.

No, that would be wrong.

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.

> 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?


r~