This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Altivec + 16 byte alignment
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: mstump at apple dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 11 Feb 03 14:21:40 EST
- Subject: Re: Altivec + 16 byte alignment
I think the answer is the minimum of MAX_OFILE_ALIGNMENT,
STACK_BOUNDARY and BIGGEST_ALIGNMENT, if there are no bugs. If there
are bugs, you can't, not without fixing those bugs.
Well, then there's another bug. Look at the usage of REGNO_POINTER_ALIGNMENT
in combine.c: it assumes that the bits not in that alignment are zero.
Then look at all the calls to mark_reg_pointer that just pass TYPE_ALIGN
or DECL_ALIGN but nothing performs the minimum above before setting those.
But I must say that
Biggest alignment that any data type can require on this machine, in bits.
still seems in conflict with the current implementation. If a type can
*require* that alignment, doesn't that mean that we are going to *give*
it that alignment? But how can we if STACK_BOUNDARY is smaller?
I think this is a real mess at this point.