[PATCH 08/34] rs6000: Add Power9 builtins
2021-06-15 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def: Add power9-vector, power9,
and power9-64 stanzas.
---
gcc/config/rs6000/rs6000-builtin-new.def | 375 +++
1 file changed, 375 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
b/gcc/config/rs6000/rs6000-builtin-new.def
index f13fb13b0ad..8885df089a6 100644
--- a/gcc/config/rs6000/rs6000-builtin-new.def
+++ b/gcc/config/rs6000/rs6000-builtin-new.def
@@ -2434,3 +2434,378 @@
const double __builtin_vsx_xscvspdpn (vf);
XSCVSPDPN vsx_xscvspdpn {}
+
+
+; Power9 vector builtins.
+[power9-vector]
+ const vss __builtin_altivec_convert_4f32_8f16 (vf, vf);
+CONVERT_4F32_8F16 convert_4f32_8f16 {}
+
+ const vss __builtin_altivec_convert_4f32_8i16 (vf, vf);
+CONVERT_4F32_8I16 convert_4f32_8i16 {}
+
+ const signed int __builtin_altivec_first_match_index_v16qi (vsc, vsc);
+VFIRSTMATCHINDEX_V16QI first_match_index_v16qi {}
+
+ const signed int __builtin_altivec_first_match_index_v8hi (vss, vss);
+VFIRSTMATCHINDEX_V8HI first_match_index_v8hi {}
+
+ const signed int __builtin_altivec_first_match_index_v4si (vsi, vsi);
+VFIRSTMATCHINDEX_V4SI first_match_index_v4si {}
+
+ const signed int __builtin_altivec_first_match_or_eos_index_v16qi (vsc, vsc);
+VFIRSTMATCHOREOSINDEX_V16QI first_match_or_eos_index_v16qi {}
+
+ const signed int __builtin_altivec_first_match_or_eos_index_v8hi (vss, vss);
+VFIRSTMATCHOREOSINDEX_V8HI first_match_or_eos_index_v8hi {}
+
+ const signed int __builtin_altivec_first_match_or_eos_index_v4si (vsi, vsi);
+VFIRSTMATCHOREOSINDEX_V4SI first_match_or_eos_index_v4si {}
+
+ const signed int __builtin_altivec_first_mismatch_index_v16qi (vsc, vsc);
+VFIRSTMISMATCHINDEX_V16QI first_mismatch_index_v16qi {}
+
+ const signed int __builtin_altivec_first_mismatch_index_v8hi (vss, vss);
+VFIRSTMISMATCHINDEX_V8HI first_mismatch_index_v8hi {}
+
+ const signed int __builtin_altivec_first_mismatch_index_v4si (vsi, vsi);
+VFIRSTMISMATCHINDEX_V4SI first_mismatch_index_v4si {}
+
+ const signed int __builtin_altivec_first_mismatch_or_eos_index_v16qi (vsc,
vsc);
+VFIRSTMISMATCHOREOSINDEX_V16QI first_mismatch_or_eos_index_v16qi {}
+
+ const signed int __builtin_altivec_first_mismatch_or_eos_index_v8hi (vss,
vss);
+VFIRSTMISMATCHOREOSINDEX_V8HI first_mismatch_or_eos_index_v8hi {}
+
+ const signed int __builtin_altivec_first_mismatch_or_eos_index_v4si (vsi,
vsi);
+VFIRSTMISMATCHOREOSINDEX_V4SI first_mismatch_or_eos_index_v4si {}
+
+ const vsc __builtin_altivec_vadub (vsc, vsc);
+VADUB vaduv16qi3 {}
+
+ const vss __builtin_altivec_vaduh (vss, vss);
+VADUH vaduv8hi3 {}
+
+ const vsi __builtin_altivec_vaduw (vsi, vsi);
+VADUW vaduv4si3 {}
+
+ const vsll __builtin_altivec_vbpermd (vsll, vsc);
+VBPERMD altivec_vbpermd {}
+
+ const signed int __builtin_altivec_vclzlsbb_v16qi (vsc);
+VCLZLSBB_V16QI vclzlsbb_v16qi {}
+
+ const signed int __builtin_altivec_vclzlsbb_v4si (vsi);
+VCLZLSBB_V4SI vclzlsbb_v4si {}
+
+ const signed int __builtin_altivec_vclzlsbb_v8hi (vss);
+VCLZLSBB_V8HI vclzlsbb_v8hi {}
+
+ const vsc __builtin_altivec_vctzb (vsc);
+VCTZB ctzv16qi2 {}
+
+ const vsll __builtin_altivec_vctzd (vsll);
+VCTZD ctzv2di2 {}
+
+ const vss __builtin_altivec_vctzh (vss);
+VCTZH ctzv8hi2 {}
+
+ const vsi __builtin_altivec_vctzw (vsi);
+VCTZW ctzv4si2 {}
+
+ const signed int __builtin_altivec_vctzlsbb_v16qi (vsc);
+VCTZLSBB_V16QI vctzlsbb_v16qi {}
+
+ const signed int __builtin_altivec_vctzlsbb_v4si (vsi);
+VCTZLSBB_V4SI vctzlsbb_v4si {}
+
+ const signed int __builtin_altivec_vctzlsbb_v8hi (vss);
+VCTZLSBB_V8HI vctzlsbb_v8hi {}
+
+ const signed int __builtin_altivec_vcmpaeb_p (vsc, vsc);
+VCMPAEB_P vector_ae_v16qi_p {}
+
+ const signed int __builtin_altivec_vcmpaed_p (vsll, vsll);
+VCMPAED_P vector_ae_v2di_p {}
+
+ const signed int __builtin_altivec_vcmpaedp_p (vd, vd);
+VCMPAEDP_P vector_ae_v2df_p {}
+
+ const signed int __builtin_altivec_vcmpaefp_p (vf, vf);
+VCMPAEFP_P vector_ae_v4sf_p {}
+
+ const signed int __builtin_altivec_vcmpaeh_p (vss, vss);
+VCMPAEH_P vector_ae_v8hi_p {}
+
+ const signed int __builtin_altivec_vcmpaew_p (vsi, vsi);
+VCMPAEW_P vector_ae_v4si_p {}
+
+ const vsc __builtin_altivec_vcmpneb (vsc, vsc);
+VCMPNEB vcmpneb {}
+
+ const signed int __builtin_altivec_vcmpneb_p (vsc, vsc);
+VCMPNEB_P vector_ne_v16qi_p {}
+
+ const signed int __builtin_altivec_vcmpned_p (vsll, vsll);
+VCMPNED_P vector_ne_v2di_p {}
+
+ const signed int __builtin_altivec_vcmpnedp_p (vd, vd);
+VCMPNEDP_P vector_ne_v2df_p {}
+
+ const signed int __builtin_altivec_vcmpnefp_p (vf, vf);
+VCMPNEFP_P vector_ne_v4sf_p {}
+
+ const vss __builtin_altivec_vcmpneh (vss, vss);
+VCMPNEH vcmpneh {}
+
+ const signed int __builtin_altivec_vcmpneh_p (vss, vss);
+VCMPNEH_P vector_ne_v8hi_p {}
+
+ const vsi __builtin_altivec
Re: [PATCH 08/34] rs6000: Add Power9 builtins
On Thu, Jul 29, 2021 at 08:30:55AM -0500, Bill Schmidt wrote: > 2021-06-15 Bill Schmidt > * config/rs6000/rs6000-builtin-new.def: Add power9-vector, power9, > and power9-64 stanzas. > +; 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. That is wrong then? It should never have TARGET_64BIT if it isn't addressing memory (or the like). Did you just typo this? > +; On the other hand, xsxsigdp has a result that doesn't fit in > +; 32 bits, and the return value is DImode, so it seems that > +; TARGET_64BIT (actually TARGET_POWERPC64) is justified. TBD. Because xsxsigdp needs it, it makes sense to have it for xsxexpdp as well, or we would get a weird holey API. Okay for trunk (with the typo fixed if it is one). Thanks! Segher
Re: [PATCH 08/34] rs6000: Add Power9 builtins
On 8/23/21 4:40 PM, Segher Boessenkool wrote: On Thu, Jul 29, 2021 at 08:30:55AM -0500, Bill Schmidt wrote: 2021-06-15 Bill Schmidt * config/rs6000/rs6000-builtin-new.def: Add power9-vector, power9, and power9-64 stanzas. +; 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. That is wrong then? It should never have TARGET_64BIT if it isn't addressing memory (or the like). Did you just typo this? Not a typo... I was referring to the condition in the following: ;; VSX Scalar Extract Exponent Double-Precision (define_insn "xsxexpdp" [(set (match_operand:DI 0 "register_operand" "=r") (unspec:DI [(match_operand:DF 1 "vsx_register_operand" "wa")] UNSPEC_VSX_SXEXPDP))] "TARGET_P9_VECTOR && TARGET_64BIT" "xsxexpdp %0,%x1" [(set_attr "type" "integer")]) +; On the other hand, xsxsigdp has a result that doesn't fit in +; 32 bits, and the return value is DImode, so it seems that +; TARGET_64BIT (actually TARGET_POWERPC64) is justified. TBD. Because xsxsigdp needs it, it makes sense to have it for xsxexpdp as well, or we would get a weird holey API. OK. Based on this, I think I will just remove the comments here. Thanks very much for the review! Bill Okay for trunk (with the typo fixed if it is one). Thanks! Segher
Re: [PATCH 08/34] rs6000: Add Power9 builtins
Hi! On Tue, Aug 24, 2021 at 09:20:09AM -0500, Bill Schmidt wrote: > On 8/23/21 4:40 PM, Segher Boessenkool wrote: > >On Thu, Jul 29, 2021 at 08:30:55AM -0500, Bill Schmidt wrote: > >>+; 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. > >That is wrong then? It should never have TARGET_64BIT if it isn't > >addressing memory (or the like). Did you just typo this? > > Not a typo... I was referring to the condition in the following: > > ;; VSX Scalar Extract Exponent Double-Precision > (define_insn "xsxexpdp" > [(set (match_operand:DI 0 "register_operand" "=r") > (unspec:DI [(match_operand:DF 1 "vsx_register_operand" "wa")] > UNSPEC_VSX_SXEXPDP))] > "TARGET_P9_VECTOR && TARGET_64BIT" > "xsxexpdp %0,%x1" > [(set_attr "type" "integer")]) That looks wrong. It should be TARGET_POWERPC64 afaics. > >>+; On the other hand, xsxsigdp has a result that doesn't fit in > >>+; 32 bits, and the return value is DImode, so it seems that > >>+; TARGET_64BIT (actually TARGET_POWERPC64) is justified. TBD. > >Because xsxsigdp needs it, it makes sense to have it for xsxexpdp as > >well, or we would get a weird holey API. Both should have TARGET_POWERPC64 (and the underlying patterns as well of course, we don't like ICEs so much). Segher
Re: [PATCH 08/34] rs6000: Add Power9 builtins
On 8/24/21 10:38 AM, Segher Boessenkool wrote: Hi! On Tue, Aug 24, 2021 at 09:20:09AM -0500, Bill Schmidt wrote: On 8/23/21 4:40 PM, Segher Boessenkool wrote: On Thu, Jul 29, 2021 at 08:30:55AM -0500, Bill Schmidt wrote: +; 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. That is wrong then? It should never have TARGET_64BIT if it isn't addressing memory (or the like). Did you just typo this? Not a typo... I was referring to the condition in the following: ;; VSX Scalar Extract Exponent Double-Precision (define_insn "xsxexpdp" [(set (match_operand:DI 0 "register_operand" "=r") (unspec:DI [(match_operand:DF 1 "vsx_register_operand" "wa")] UNSPEC_VSX_SXEXPDP))] "TARGET_P9_VECTOR && TARGET_64BIT" "xsxexpdp %0,%x1" [(set_attr "type" "integer")]) That looks wrong. It should be TARGET_POWERPC64 afaics. +; On the other hand, xsxsigdp has a result that doesn't fit in +; 32 bits, and the return value is DImode, so it seems that +; TARGET_64BIT (actually TARGET_POWERPC64) is justified. TBD. Because xsxsigdp needs it, it makes sense to have it for xsxexpdp as well, or we would get a weird holey API. Both should have TARGET_POWERPC64 (and the underlying patterns as well of course, we don't like ICEs so much). Yes, the enablement support I've added uses TARGET_POWERPC64. I think we need a separate patch to fix the patterns in vsx.md. I'll take a note on that. Thanks! Bill Segher
