On Mon, 2020-07-27 at 09:14 -0500, Bill Schmidt wrote:
> From: Bill Schmidt <wschm...@linux.ibm.com>
>
> 2020-07-26 Bill Schmidt <wschm...@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, ... )
<snip>
> +; Miscellaneour P9 functions
Miscellaneous :-)
<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 ?
> +; 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
