From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id B174D3850425 for ; Fri, 13 May 2022 17:10:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B174D3850425 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24DFjWX4002559; Fri, 13 May 2022 17:10:23 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g1t8p1m2b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 May 2022 17:10:23 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 24DGtoVQ011565; Fri, 13 May 2022 17:10:22 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g1t8p1m1j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 May 2022 17:10:22 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 24DH7uI8022449; Fri, 13 May 2022 17:10:21 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma04wdc.us.ibm.com with ESMTP id 3fwgdabqrf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 May 2022 17:10:21 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24DHAKMV29098416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 May 2022 17:10:20 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DADC2124055; Fri, 13 May 2022 17:10:20 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5800F124054; Fri, 13 May 2022 17:10:20 +0000 (GMT) Received: from lexx (unknown [9.160.59.210]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 13 May 2022 17:10:20 +0000 (GMT) Message-ID: Subject: Re: [PATCH] Optimize vec_splats of constant V2DI/V2DF vec_extract, PR target/99293 From: will schmidt To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner Date: Fri, 13 May 2022 12:10:19 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: ovjhtBtxz01c9tuj8NBkKNbv8Yfh5WjB X-Proofpoint-ORIG-GUID: BVWVlYKhK6z_hq8ZAGspQIpyUWhYDeJn Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-13_09,2022-05-13_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 bulkscore=0 clxscore=1015 adultscore=0 mlxscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205130073 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 17:10:26 -0000 On Fri, 2022-05-13 at 10:49 -0400, Michael Meissner wrote: > Optimize vec_splats of constant V2DI/V2DF vec_extract, PR target/99293. > > This patch has been previously posted, but it seemed to get lost.: > > > Date: Tue, 29 Mar 2022 23:25:31 -0400 > > Subject: [PATCH, V2] Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293. > > Message-ID: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592509.html > > I had originally posted a previous version of this patch here. There were > changes asked for, which I did in this patch. > > > Date: Mon, 28 Mar 2022 12:26:02 -0400 > > Subject: [PATCH 1/4] Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293. > > Message-ID: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592420.html > Hi, generally lgtm. A few typos and comment suggests called out below. Thanks. -Will > In PR target/99293, it was pointed out that doing: > > vector long long dest0, dest1, src; > /* ... */ > dest0 = vec_splats (vec_extract (src, 0)); > dest1 = vec_splats (vec_extract (src, 1)); > > would generate slower code. > > It generates the following code on power8: > > ;; vec_splats (vec_extract (src, 0)) > xxpermdi 0,34,34,3 > xxpermdi 34,0,0,0 > > ;; vec_splats (vec_extract (src, 1)) > xxlor 0,34,34 > xxpermdi 34,0,0,0 > > However on power9 and power10 it generates: > > ;; vec_splats (vec_extract (src, 0)) > mfvsld 3,34 > mtvsrdd 34,9,9 > > ;; vec_splats (vec_extract (src, 1)) > mfvsrd 9,34 > mtvsrdd 34,9,9 > > This is due to the power9 having the mfvsrld instruction which can extract > either 64-bit element into a GPR. While there are alternatives for both > vector registers and GPR registers, the register allocator prefers to put > DImode into GPR registers. > > However in this case, it is better to have a single combiner pattern that > can generate a single xxpermdi, instead of doing 2 insnsns (the extract I like the idea of insnsns being the plural of insn. > and then the concat). This is particularly true if the two operations are > move from vector register and move to vector register. As Segher pointed > out in a previous version of the patch, the combiner already tries doing s/doing// > creating a (vec_duplicate (vec_select ...)) pattern, but we didn't provide > one. > > This patch reworks vsx_xxspltd_ for V2DImode and V2DFmode so that it > no longer uses an UNSPEC. Instead it uses VEC_DUPLICATE, which the > combiner checks for. potentially s/no longer uses an UNSPEC. Instead it uses/now uses/ and possibly s/ch ecks for/can find/ > > I have built Spec 2017 with this patch installed, and the cam4_r benchmark > is the only benchmark that generated different code (3 mfvsrld/mtvsrdd > pairs of instructions were replaced with xxpermdi). > > I have built bootstrap versions on the following systems and I have run > the regression tests. There were no regressions in the runs: > > Power9 little endian, --with-cpu=power9 > Power10 little endian, --with-cpu=power10 > Power8 big endian, --with-cpu=power8 (both 32-bit & 64-bit tests) > > Can I install this into the trunk? After a burn-in period, can I backport > and install this into GCC 12, GCC 11 and GCC 10 branches? > > 2022-05-13 Michael Meissner > > gcc/ > PR target/99293 > * config/rs6000/rs6000-p8swap.cc (rtx_is_swappable_p): Remove > UNSPEC_VSX_XXSPLTD case. > * config/rs6000/vsx.md (UNSPEC_VSX_XXSPLTD): Delete. > (vsx_xxspltd_): Rewrite to use VEC_DUPLICATE. > > gcc/testsuite: > PR target/99293 > * gcc.target/powerpc/builtins-1.c: Update insn count. > * gcc.target/powerpc/pr99293.c: New test. > --- > gcc/config/rs6000/rs6000-p8swap.cc | 1 - > gcc/config/rs6000/vsx.md | 19 +++++----- > gcc/testsuite/gcc.target/powerpc/builtins-1.c | 2 +- > gcc/testsuite/gcc.target/powerpc/pr99293.c | 36 +++++++++++++++++++ > 4 files changed, 47 insertions(+), 11 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/powerpc/pr99293.c > > diff --git a/gcc/config/rs6000/rs6000-p8swap.cc b/gcc/config/rs6000/rs6000-p8swap.cc > index d301bc3fe59..1973d9c8245 100644 > --- a/gcc/config/rs6000/rs6000-p8swap.cc > +++ b/gcc/config/rs6000/rs6000-p8swap.cc > @@ -805,7 +805,6 @@ rtx_is_swappable_p (rtx op, unsigned int *special) > case UNSPEC_VUPKLU_V4SF: > return 0; > case UNSPEC_VSPLT_DIRECT: > - case UNSPEC_VSX_XXSPLTD: > *special = SH_SPLAT; > return 1; > case UNSPEC_REDUC_PLUS: ok > diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md > index 1b75538f42f..a1a1ce95195 100644 > --- a/gcc/config/rs6000/vsx.md > +++ b/gcc/config/rs6000/vsx.md > @@ -296,7 +296,6 @@ (define_c_enum "unspec" > UNSPEC_VSX_XXPERM > > UNSPEC_VSX_XXSPLTW > - UNSPEC_VSX_XXSPLTD > UNSPEC_VSX_DIVSD > UNSPEC_VSX_DIVUD > UNSPEC_VSX_DIVSQ > @@ -4673,16 +4672,18 @@ (define_insn "vsx_vsplt_di" > ;; V2DF/V2DI splat for use by vec_splat builtin > (define_insn "vsx_xxspltd_" > [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa") > - (unspec:VSX_D [(match_operand:VSX_D 1 "vsx_register_operand" "wa") > - (match_operand:QI 2 "u5bit_cint_operand" "i")] > - UNSPEC_VSX_XXSPLTD))] > + (vec_duplicate:VSX_D > + (vec_select: > + (match_operand:VSX_D 1 "gpc_reg_operand" "wa") > + (parallel [(match_operand:QI 2 "const_0_to_1_operand" "i")]))))] > "VECTOR_MEM_VSX_P (mode)" > { > - if ((BYTES_BIG_ENDIAN && INTVAL (operands[2]) == 0) > - || (!BYTES_BIG_ENDIAN && INTVAL (operands[2]) == 1)) > - return "xxpermdi %x0,%x1,%x1,0"; > - else > - return "xxpermdi %x0,%x1,%x1,3"; > + HOST_WIDE_INT dword = INTVAL (operands[2]); > + if (!BYTES_BIG_ENDIAN) > + dword = !dword; > + > + operands[3] = GEN_INT (3*dword); > + return "xxpermdi %x0,%x1,%x1,%3"; > } > [(set_attr "type" "vecperm")]) ok > > diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1.c b/gcc/testsuite/gcc.target/powerpc/builtins-1.c > index 28cd1aa6b1a..98783668bce 100644 > --- a/gcc/testsuite/gcc.target/powerpc/builtins-1.c > +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1.c > @@ -1035,4 +1035,4 @@ foo156 (vector unsigned short usa) > /* { dg-final { scan-assembler-times {\mvmrglb\M} 3 } } */ > /* { dg-final { scan-assembler-times {\mvmrgew\M} 4 } } */ > /* { dg-final { scan-assembler-times {\mvsplth|xxsplth\M} 4 } } */ > -/* { dg-final { scan-assembler-times {\mxxpermdi\M} 44 } } */ > +/* { dg-final { scan-assembler-times {\mxxpermdi\M} 42 } } */ > diff --git a/gcc/testsuite/gcc.target/powerpc/pr99293.c b/gcc/testsuite/gcc.target/powerpc/pr99293.c > new file mode 100644 > index 00000000000..d2a3b4401c5 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr99293.c > @@ -0,0 +1,36 @@ > +/* { dg-do compile } */ > +/* { dg-require-effective-target powerpc_vsx_ok } */ > +/* { dg-options "-O2 -mvsx" } */ > + > +/* Test for PR 99263, which wants to do: > + __builtin_vec_splats (__builtin_vec_extract (v, n)) > + > + where v is a V2DF or V2DI vector and n is either 0 or 1. Previously the > + compiler would do a direct move to the GPR registers to select the item and > + a direct move from the GPR registers to do the splat. */ A good comment, but would be better if it described the current behavior, versus what the behavior used to be. Could probably be reworked to stl s/Previously.../ This test insures that the result of the splats now results in an xxpermdi for these scenarios. Prior to the fix for PR99263 the generated code was mfvs#d and mtvsrdd, which is nonoptimal. > + > +vector long long > +splat_dup_ll_0 (vector long long v) > +{ > + return __builtin_vec_splats (__builtin_vec_extract (v, 0)); > +} > + > +vector long long > +splat_dup_ll_1 (vector long long v) > +{ > + return __builtin_vec_splats (__builtin_vec_extract (v, 1)); > +} > + > +vector double > +splat_dup_d_0 (vector double v) > +{ > + return __builtin_vec_splats (__builtin_vec_extract (v, 0)); > +} > + > +vector double > +splat_dup_d_1 (vector double v) > +{ > + return __builtin_vec_splats (__builtin_vec_extract (v, 1)); > +} > + > +/* { dg-final { scan-assembler-times {\mxxpermdi\M} 4 } } */ > -- > 2.35.3 > >