[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