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

[Bill Schmidt]

On 2/14/20 4:09 PM, Jakub Jelinek 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,
> 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.

Bill

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