This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Altivec + 16 byte alignment
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: rth at redhat dot com (Richard Henderson)
- Cc: Franz dot Sirl-kernel at lauterbach dot com, gcc at gcc dot gnu dot org, gianni at scaramanga dot co dot uk
- Date: Wed, 12 Feb 2003 17:31:20 -0500 (EST)
- Subject: Re: Altivec + 16 byte alignment
> If yes, then STACK_ALIGNMENT is set too low. You should
> advertise what you have. If no, then calling between two
> functions compiled with different compilers will not
> preserve the 256 bit alignment you claim.
You mean STACK_BOUNDARY?
> 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.
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.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)