Re: altivec fix for starting_frame_offset

[Richard Henderson <rth at redhat dot com>]

On Wed, Feb 27, 2002 at 06:58:48PM -0500, David Edelsohn wrote:
> 	And your proposal is not correct.  The Altivec ABI is backward
> compatible with the non-Altivec ABI.  Any patch which sets
> FIRST_PARM_OFFSET and STACK_POINTER_OFFSET differently based upon
> TARGET_ALTIVEC_ABI is by definition wrong.

That's just Aldy being paranoid.  They can be changed unconditionally.

>    AIX (and Darwin/Mac OS X) stack frames look like:
> 
> 16 byte aligned
>         SP----> +---------------------------------------+
>                 | back chain to caller                  | 0
>                 +---------------------------------------+
>                 | saved CR                              | 4
>                 +---------------------------------------+
>                 | saved LR                              | 8
>                 +---------------------------------------+
>                 | reserved for compilers                | 12
>                 +---------------------------------------+
>                 | reserved for binders                  | 16
>                 +---------------------------------------+
>                 | saved TOC pointer                     | 20

virtual_outgoing_args_rtx ->
>                 +---------------------------------------+
>                 | GPR/FPR Parameter save area (P)       | 24
>                 +---------------------------------------+
> #1 -----------> | Altivec alignment                     |
> 16 byte aligned +---------------------------------------+
>                 | VR Parameter save area (VRP)          |
>                 +---------------------------------------+
[...]
> 	I believe what is needed is some tweaks to the function_arg
> routines so it potentially skips some parameter area words to access the
> first vector parameter, not shifting the start of any parameter area.

Actually, function_arg *cannot* handle sorting parameters to the
end of the list.  I had not been told about this feature of your
ABI before.  It will take major surgery to change this.

However, that's immaterial to "shifting the start of any
parameter area" as you say.

The root of the problem (ignoring parameter ordering) is that
GCC assumes that virtual_outgoing_args_rtx is as aligned as
the stack pointer.  That is not the case for 32-bit AIX.
Therefore, all of the alignment that GCC does try to enforce
for the argument lists comes out wrong.

Therefore, we must create a definition of virtual_outgoing_args_rtx
that *is* suitibly aligned.

Therefore, I suggested that the displacement between 
virtual_outgoing_args_rtx and stack_pointer_rtx (STACK_POINTER_OFFSET)
be set to zero, and arrange for the first argument to be at a
non-zero offset from virtual_outgoing_args_rtx, which was not
previously possible.

Therefore I believe my proposal to be correct.

The question of argument ordering is something else.

Please refute this without once mentioning STARTING_FRAME_OFFSET,
which is irrelevant to parameter passing.


r~