[RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
Jakub Jelinek
jakub@redhat.com
Sun Feb 23 17:33:00 GMT 2020
On Sun, Feb 23, 2020 at 10:42:17AM -0600, Bill Schmidt wrote:
> > > Have I missed something crucial?
> > I haven't seen anything in the patch that would only enable it for ELFv2,
> > and while powerpc64le-linux probably assumes TARGET_VSX unconditionally
> > (haven't verified), powerpc64-linux or powerpc-linux certainly doesn't.
> > And it is just fine to have the ABI for those pass/return vectors in VSX
> > registers too, after all, it won't be used if the vectorized caller isn't
> > TARGET_VSX, the definitions of the declare simd functions could be compiled
> > with different ISA options. And, if the ABI sais that the 'b' stuff assumes
> > certain ISA extensions, if the declare simd function definition is compiled
> > with e.g. -mno-vsx -mno-altivec, it would either not be able to get the
> > arguments/return values at all, or wouldn't benefit from the ISA guarantees
> > the ABI gives to it.
>
> It's a problem with the patch that it doesn't limit the ABI to ELFv2. That is
> necessary, because there are aspects of the vector ABI that are incompatible
> with ELFv1. In particular, ELFv1 doesn't support returning homogeneous
> aggregates of vectors in vector registers, which is called for in the proposed
> sincos interface, and would also be needed for vectorized complex functions.
Is it really a problem? I mean, it is perfectly fine if the declare simd
variants have a different ABI from the normal ABI, just for #pragma omp
declare variant it will be desirable if there is some attribute for such
different (or just slightly amended) ABI. And vector complex is not an
issue right now, we punt on those on all architectures.
Jakub
More information about the Gcc-patches
mailing list