[PATCH, PowerPC] ABI fixes / improvements for powerpc64-linux

[Ulrich Weigand]

Hal Finkel <hfinkel at anl.gov> wrote on 09.07.2014 21:19:56:

> I don't understand how this works. If the type has a larger
> alignment requirement, then you can either:
>
>  1. Pass a pointer to it, or
>  2. Make sure it is aligned in the parameter save area as requested.
>  3. Pass it underaligned, and then memcpy it to an aligned place in
> the callee's stack frame.
>
> When you have a greater-than-16-byte alignment specified, the caller
> and/or callee might need to do a dynamic stack realignment to make
> things work, but that's already implemented. The existing ABI (
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html
> ), as far as I can tell says nothing about aggregates being
> restricted to 16-byte alignment.

Yes, the ABI doc is wrong here.  We'll fix this in the new version
we're currently working on.  What was intended (and what is
implemented in GCC today) is somewhat of a mixture of 2 and 3
above: if the type's alignment requirement is >= 16 byte,  it
will be passed in the save area at 16 byte alignment.

The rationale is the this: alignment in the parameter save area
matters for two reasons:
- if you take the address of the parameter, it has to be properly
  aligned, since code is allowed to assume that property;
- when you access a member of the parameter in place in the save
  area, the ISA may have alignment requirements; on PowerPC, the
  only such requirement is 16 byte for VMX loads/stores.

The reason why an argument in the save area is 16-byte aligned
is that this will suffice for the second reason above, i.e. it
is possible to access the argument using VMX instructions.

If the argument type actually requires > 16 byte alignment,
and code indeed takes the address of the argument, then the
compiler will have to copy the incoming argument to another
place, properly aligned, on the stack.


Bye,
Ulrich