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: geoffk at geoffk dot org
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 11 Feb 03 14:46:33 EST
- Subject: Re: Altivec + 16 byte alignment
Such code is wrong, it should be using MAX_OFILE_ALIGNMENT. Can you
point at the code in question?
The one in combine.c I mentioned in my last message, for example.
Yes, it's supposed to be. STACK_BOUNDARY is a minimum, not a maximum.
I don't follow. STACK_BOUNDARY indeed gives the mimimum that the stack
is guaranteed to be aligned. That's therefore the maximum that we can
guarantee to align any variable.
In the abstract, you compare with MAX_OFILE_BOUNDARY. You can align
the stack to any value you like,
Who's the "you"? Where's the code? If we have STACK_BOUNDARY of 32,
MAX_OFILE_BOUNDARY of 1024 and a TYPE_ALIGN of 128, what code is
responsible for aligning that variable to a boundary of 128 bits?
/* Ignore alignment we can't do with expected alignment of the
boundary. */
if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
but really that's wrong, and at a minimum it should warn the user
that their requested alignment isn't going to happen (better would be
to just ensure the requested alignment). We occasionally get bug
reports about this, but so far no-one has invested the effort to
implement arbitrary stack alignment.
Now we have *yet another* macro involved in alignment!