This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: altivec fix for starting_frame_offset
- From: Richard Henderson <rth at redhat dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 1 Mar 2002 11:19:39 -0800
- Subject: Re: altivec fix for starting_frame_offset
- References: <rth@redhat.com> <200203011905.OAA20848@makai.watson.ibm.com>
On Fri, Mar 01, 2002 at 02:05:18PM -0500, David Edelsohn wrote:
> 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.
This is possible, if exceedingly ugly.
You'll need a hard argument pointer register instead of a fake one
to be eliminated during reload. You'll need to forcibly align the
stack during the prologue and initialize your hard argument pointer.
You'll need to be careful during the epilogue to unwind things properly.
Thank goodness this is only needed on AIX, and not SVR4 or Darwin.
I don't expect Aldy to implement this any time soon.
> 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?
Because on some machines it is not constant. Examine the definition
of STACK_POINTER_OFFSET for pa64, for instance.
r~