altivec fix for starting_frame_offset

[David Edelsohn]

>>>>> Richard Henderson writes:

Richard> In order to be able to do alignment in any sensible way, gcc has to
Richard> assume that virtual_outgoing_args is *at least* as aligned as any value
Richard> returned by FUNCTION_ARG_BOUNDARY.  Otherwise how can we possibly 
Richard> determine whether or not any offset from virtual_outgoing_args is
Richard> properly aligned?

	We can determine the alignment of offsets from
virtual_outgoing_args using the alignment of the link area and
CUMULATIVE_ARGS.  We know the alignment of the stack, that the stack has
the *same* alignment as the strictest parameter alignment, and the exact,
constant offset of the parameter area from the stack.  CUMULATIVE_ARGS
tells us our current offset, and therefor our current alignment.  There is
no question whether a particular doubleword-alined offset from
virtual_outgoing_args will or will not be quadword aligned when Altivec
ABI is enabled.

	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.

	*WITH* Altivec, we know that the stack is quadword align.  The
parameter area is 24 bytes offset from quadword alignment meaning it must
be doubleword aligned and *not* quadword aligned.  We know that PW2
(cum->words = 2), PW6 (cum->words = 6), PW10 (cum->words = 10), PW14
(cum->words = 14), PW18 (cum->words = 18), etc. are quadword aligned.  In
other words, virtual_outgoing_args + 8, virtual_outgoing_args + 24,
virtual_outgoing_args + 40, virtual_outgoing_args + 56,
virtual_outgoing_args + 72, etc. are quadword aligned.  We cannot possibly
be out of phase if the stack was properly aligned.

	GCC can know the exact alignment of virtual_outgoing_args needed
to make decisions about how to align any possible parameter.

	The Altivec ABI is backward compatible with the old ABI.  One can
intermix Altivec and non-Altivec routines.  If GCC assumes that the
previous stack frame is an Altivec stack frame aligned to quadword
alignment guaranteeing any 16-byte rounded stack adjustment will provide a
quadword-aligned stack, WE ALREADY ARE BROKEN.

	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.

	I understand the concept of your proposal to obtain the necessary
alignment, but I still do not see why it is necessary.  Why does GCC
require that the stack and virtual_outgoing_args have the same alignment
when the relationship is fixed making the relative alignment of
virtual_outgoing_args constant and known?

Thanks, David