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.

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.


Reply via email to