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

[Hal Finkel]

----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "cfe commits" <cfe-commits at cs.uiuc.edu>
> Sent: Wednesday, July 9, 2014 5:48:38 PM
> Subject: Re: [PATCH, PowerPC] ABI fixes / improvements for powerpc64-linux
> 
> Hal Finkel <hfinkel at anl.gov> wrote on 10.07.2014 00:08:57:
> 
> > > 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.
> >
> > As I noted in my last e-mail, the current LLVM implementation does
> > not look like it skips registers when it adjusts the alignment
> > offset. I'm happy to see a compatibility fix for that (although I'm
> > unhappy that the current ABI requires it), but that's a separate
> > issue.
> 
> Just a quick comment on this point for now: it is not just about
> skipping registers; if you want to see the effect on in-memory
> parameter, modify the example to something like:
> 
> struct pad { long x[11]; };
> struct test { long x; } __attribute__((aligned (128)));
> 
> long callee (struct pad x, struct test y)
> {
>   return y.x;
> }
> 
> In this case, GCC (and clang with patch) will expect y.x at 144(1),
> while clang without patch will expect y.x at 136(1); in neither case
> do we have 128-byte alignment.
> 
> [ As you say, LLVM apparently would handle over-aligned byval
> parameters,
> but clang currently never actually passes any byval align value, so
> that
> may be why that code doesn't trigger here.  ]

Indeed, that certainly seems like a bug.

> 
> At this point, my intent with the clang patch I proposed was simply
> to make clang compatible with GCC on the old ABI as-is.

I understand.

> 
> 
> The new ELFv2 ABI is really a separate issue, and I'm planning to
> post
> patches to implement this soon; but as a general statement, an
> implementation
> of the new ABI is also already in the field, it's been in GCC since
> last
> year
> and full Linux distributions have been built with it; so again I
> don't see
> much chance at this point to actually change the ABI, but simply to
> make
> sure it is implemented in LLVM in a compatible way ...

The new ABI has not yet been published, and I doubt that changing interactions with over-aligned types, vector types, etc. will break much (if anything at all) in this already-built Linux distribution. However, getting these things right affects the performance of internal interfaces of performance-tuned codes (especially those that use over-aligned structures, vector intrinsics, etc.) and there is no reason to do a bad job in that area now.

In other news, there is a supported Linux distro that ships with TOT gcc?

Thanks again,
Hal

> 
> 
> Bye,
> Ulrich
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory