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

[Ulrich Weigand]

Hal Finkel <hfinkel at anl.gov> wrote on 09.07.2014 22:37:57:

> Unfortunately, this logic is flawed. When a user specifies an
> enhanced alignment for a structure, it is normally for performance
> reasons (often so that it will start on a cache-line boundary). This
> difference is potentially observable (in practice) regardless of
> whether the address is taken.

Well, those cases where performance count rarely involve structs
passed by value :-)

> Currently, in LLVM, when a local alloca (and this should include
> byval parameters) require enhanced alignment, this triggers a
> dynamic stack realignment (in the caller and/or callee). The offset
> in the parameter save area is then also adjusted to ensure the
> proper alignment (*)
>
> So, yes, this requires some additional pointer arithmetic to work
> correctly. However, that's already implemented, and I believe this
> currently works correctly. Don't break it (and if the new, yet
> unpublished, ABI will require breaking it, please change the ABI).

It is not that the new ABI requires anything different, we simply
brought the written ABI in line with what compilers actually did
even with the old ABI.  No compiler ever aligned a parameter in
the save area to more than 16 bytes; changing this at this point
doesn't seem feasible.

For example:

struct test { long x; } __attribute__((aligned (128)));

long callee (long x, struct test y)
{
  return y.x;
}

This expects y.x to be in r5 with GCC, and with LLVM with my patch;
LLVM without the patch currently expects it in r4.

ELFv2 and ELFv1 are not intended to differ w.r.t. alignment in the
parameter area here.


Bye,
Ulrich