Re: altivec fix for starting_frame_offset

[Alex Rosenberg <alexr at spies dot com>]

on 3/1/02 11:05 AM, David Edelsohn at dje@watson.ibm.com wrote:

> Without Altivec, we know that the stack is doubleword aligned, the
> parameter area is doubleword aligned, and we can advance the parameter
> word index to obtain the necessary doubleword alignment for a parameter,
> as specified in the ABI.

Despite this doubleword alignment guarantee, I've found myself embroiled in
four different debugging sessions that blamed some AltiVec code when in fact
some application code up the stack misaligned the stack to a word boundary.
These bugs have tended to manifest themselves as incorrect blits. They were
subtle and tedious to track down. It would be worse with audio.

> GCC has to be able to guarantee that it is providing an aligned
> stack pointer when it allocates a new stack frame on a previous stack
> frame which may have less alignment.  From there, we can know the
> alignment of every stack slot in that frame.

The AltiVec PIM clearly shows the rlwinm instruction needed to assure this
alignment for the Mac OS/AIX ABI, the SVR4 ABI, and EABI.

Only Darwin and GNU/Linux choose to align all frames to a quad boundary.

If support for this rlwinm instruction gets added, I'd suggest that it mask
an additional bit to avoid the messy sort of debugging I mentioned. Since
all AltiVec PPCs handle most misalignments in hardware and most OSes for
them handle the other misalignments, a word-aligned stack may not ever
otherwise be noticed.

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |