[PATCH 26/29] rs6000: Add Power9 builtins

[Bill Schmidt]

On 7/30/20 12:15 PM, will schmidt wrote:
> On Mon, 2020-07-27 at 09:14 -0500, Bill Schmidt wrote:
>> From: Bill Schmidt <wschmidt@linux.ibm.com>
>>
>> 2020-07-26  Bill Schmidt  <wschmidt@linux.ibm.com>
>>
>> 	* config/rs6000/rs6000-builtin-new.def: Add power9,
>> 	power9-vector, and power9-64 builtins.
>> ---
>>   gcc/config/rs6000/rs6000-builtin-new.def | 354
>> +++++++++++++++++++++++
>>   1 file changed, 354 insertions(+)
>>
>> diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
>> b/gcc/config/rs6000/rs6000-builtin-new.def
>> index 2f918c1d69e..1338f543a6a 100644
>> --- a/gcc/config/rs6000/rs6000-builtin-new.def
>> +++ b/gcc/config/rs6000/rs6000-builtin-new.def
>> @@ -2394,3 +2394,357 @@
>>       XSCVSPDPN vsx_xscvspdpn {}
>>
>>
>> +; Power9 vector builtins.
>> +[power9-vector]
>> +  const vus __builtin_altivec_convert_4f32_8i16 (vf, vf);
>> +    CONVERT_4F32_8I16 convert_4f32_8i16 {}
>> +
>> +  const unsigned int __builtin_altivec_first_match_index_v16qi (vsc,
>> vsc);
>> +    VFIRSTMATCHINDEX_V16QI first_match_index_v16qi {}
> Noting a "vus" on the previous entry, was/is a define for "ui ==
> unsigned int" considered?
> Similar question for subsequent types that are still fully spelled out.
> (unsigned char, unsigned short, ... )

I did consider it, but I feel there's a balance between keeping the 
lines short and keeping them readable.  The vector types are egregious 
space hogs, so I felt I needed to abbreviate them to avoid line wrap, 
but in most cases the scalar variables are fine with normal types.  One 
of those YMMV situations.
>
>
> <snip>
>
>> +; Miscellaneour P9 functions
>
> Miscellaneous   :-)

Thanks :)
>
> <snip>
>
>> +
>> +
>> +; These things need some review to see whether they really require
>> +; MASK_POWERPC64.  For xsxexpdp, this seems to be fine for 32-bit,
>> +; because the result will always fit in 32 bits and the return
>> +; value is SImode; but the pattern currently requires TARGET_64BIT.
>> +; On the other hand, xsssigdp has a result that doesn't fit in
> perhaps xsxsigdp ?

Indeed!

Thanks very much for the review!

Bill

>
>
>> +; 32 bits, and the return value is DImode, so it seems that
>> +; TARGET_64BIT (actually TARGET_POWERPC64) is justified.  TBD. ####
>> +[power9-64]
>> +; The following two are inexplicably named __builtin_altivec_* while
>> +; their load counterparts are __builtin_vsx_*.  Need to deprecate
>> +; these interfaces in favor of the other naming scheme (or vice
>> versa).
> Thanks
> -Will
>
>