This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Altivec + 16 byte alignment
On Wednesday 12 February 2003 22:46, Richard Henderson wrote:
> On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote:
> > ... and the stack pointer is kept aligned (to 256 bits) by
> > independent code as well
>
> Is this 256 bits ABI mandated? I.e. will a non-gcc ppc
> compiler maintain this alignment as well?
Yep, ABI mandated, 256 bits for SYSV, 128 bits for EABI.
> 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.
STACK_ALIGNMENT? I can't find that. Closest I can find is MIPS_STACK_ALIGN.
Did you think of some other macro? Sounds promising though.
Maybe part of the confusion stems from the overloaded meaning of
STACK_BOUNDARY, sometimes it means "alignment needed for the stack pointer",
sometimes "maximum alignment of objects in the frame" or similar it seems.
Hmm, do we have a function like get_frame_max_object_align()? Then each
backend could adjust alignment of the frame vs. the alignment of the
stackpointer as required.
> 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.
But this certainly isn't a problem if we _increase_ STACK_BOUNDARY like I
suggested, or?
Franz.