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
