Hi! On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote: > On 2/25/20 12:45 PM, Segher Boessenkool wrote: > >I don't agree we should have a new ABI, and an API (which this *is* as > >far as I can tell) works fine on *any* ABI. Homogeneous aggregates has > >nothing to do with anything either. > > > >It is fine to only *support* powerpc64le-linux, sure. But don't fragment > >the implementation, it only hurts, never helps -- we will end up having > >to support ten or twenty different compilers, instead of one compiler > >with a few (mostly) orthogonal variations. And yes, we should also test > >everything everywhere, whenever reasonable. > > Thanks, Segher. Let me ask for some clarification here on how you'd like > us to proceed. > > The reason that homogeneous aggregates matter (at least somewhat) is that > the ABI ^H^H^H^HAPI requires establishing a calling convention and a name- > mangling formula that includes the length of parameters and return values.
I don't see how that matters? A function that returns a struct works fine on any implementation. Sure, for small structs it can be returned in just registers on ELFv2, while some other ABIs push stuff through memory. But that is just an implementation detail of the *actual* ABI. It is good to know about this when designing the mvec stuff, sure, but this will *work* on *any* ABI. > Since ELFv2 and ELFv1 do not have the same calling convention, and ELFv2 > has a superior one, we chose to use ELFv2's calling convention and make use > of homogeneous aggregates for return values in registers for the case of > vectorized sincos. I don't understand this. You designed this API with the ELFv2 ABI in mind, sure, but that does not magically make homogeneous aggreggates appear on other ABIs, nor do you need them there. I'll read the docs again, someone is missing something here, and it probably is me ;-) Segher
