[RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[GT]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, February 14, 2020 5:09 PM, Jakub Jelinek jakub@redhat.com wrote:

> On Fri, Feb 14, 2020 at 10:02:39PM +0000, GT wrote:
>
> > > > Function rs6000_simd_clone_adjust, even though it's body is empty,
> > > > cannot simply be removed. I tried it. It resulted in ICE. In my
> > > > view, leaving it empty is preferable to modifying other files
> > > > unrelated to rs6000.c in order to avoid having a function whose
> > > > body is empty.
> > >
> > > So shouldn't the callback set target attribute (on definitions) to "vsx"?
> >
> > I did consider doing something similar to aarch64_simd_clone_adjust. But the reason
> > Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a modified
> > function calling sequence for vector functions. PPC64 vector functions use the existing
> > function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no new attribute
> > here, the function body ends up empty.
> > Have I missed something crucial?
>
> I haven't seen anything in the patch that would only enable it for ELFv2,
>

The idea is that the vector functionality defined in the ABI is guaranteed only
on systems that implement the ELFv2 ABI. It's possible that the functionality also
works on ELFv1 Big-Endian PPC64. I'll check if that's the case. If so, then the ABI
will need modification.

> and while powerpc64le-linux probably assumes TARGET_VSX unconditionally
> (haven't verified), powerpc64-linux or powerpc-linux certainly doesn't.
>

The last function in the patch, rs6000_simd_clone_usable, returns a value that will
disable use of vector variants if TARGET_VSX is undefined.

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

Don't quite understand the comment here. Are you stating the possibility of
a system that has VSX hardware but does not define macro TARGET_VSX?

> the definitions of the declare simd functions could be compiled
> with different ISA options.

Do you mean the 'b' vs 'c' in the ABI's vector function name mangling?

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

Not sure if you expect a response here.

> BTW, in the ABI document there isn't just 'b', but also 'c' ABI, it is
> unclear if one needs to always emit both (e.g. like on x86 we emit 'b', 'c',
> 'd' and 'e') and then let the vectorized callers choose based on what ISA
> options it is compiled with.
>

The reason 'c' was added to the ABI is this mailing list discussion:

https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html

As long as 'b' specifies that the VSX functionality is that specified in ISA v2.07,
I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio?

Bert.