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

[Hal Finkel]

----- Original Message -----
> From: "Hal Finkel" <hfinkel at anl.gov>
> To: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> Cc: "cfe commits" <cfe-commits at cs.uiuc.edu>
> Sent: Wednesday, July 9, 2014 6:08:47 PM
> Subject: Re: [PATCH, PowerPC] ABI fixes / improvements for powerpc64-linux
> 
> ----- 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.

To be clear, you can commit the patches -- you won't be making anything worse in practice, and you'll fix the gcc incompatibility issues. However, it is not clear to me that the current code for handling alignment of the byval parameters, or anything else, will create the necessary copies. Can you please make sure that works correctly?

Regarding the new ABI, we should have an ongoing discussion.

Thanks again,
Hal

> 
> > 
> > 
> > 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
> 

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