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 C93A2386F0ED for ; Tue, 7 Jun 2022 20:28:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C93A2386F0ED Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 257JjCYR001561; Tue, 7 Jun 2022 20:28:30 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gjd400pvk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 20:28:29 +0000 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 257KJMAs003788; Tue, 7 Jun 2022 20:28:29 GMT Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gjd400pv8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 20:28:29 +0000 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 257KKNAe021733; Tue, 7 Jun 2022 20:28:13 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma02wdc.us.ibm.com with ESMTP id 3gfy19pkkn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 20:28:13 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 257KSCtD38469960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jun 2022 20:28:12 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 38BD0124058; Tue, 7 Jun 2022 20:28:12 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A9698124053; Tue, 7 Jun 2022 20:28:11 +0000 (GMT) Received: from lexx (unknown [9.160.81.62]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 7 Jun 2022 20:28:11 +0000 (GMT) Message-ID: Subject: Re: [PATCH 1/3] Disable generating store vector pair. From: will schmidt To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner Date: Tue, 07 Jun 2022 15:28:11 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: p8wIn09CXinvUaEuOs4L45rRNMXmpzJj X-Proofpoint-GUID: MqT-HkzNCDkPjmKXyY4crwGc8DRco9z0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-07_09,2022-06-07_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 suspectscore=0 spamscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206070084 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, 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: Tue, 07 Jun 2022 20:28:32 -0000 On Mon, 2022-06-06 at 20:55 -0400, Michael Meissner wrote: > [PATCH 1/3] Disable generating store vector pair. > > Testing has revealed that the power10 has some slowdowns if the store > vector pair instruction is generated in some cases. This patch disables > generating the store vector pair instructions (stxvp, pstxvp, and stxvpx) > unless an undocumented switch is used. It is anticipated that perhaps > with future machines we can generate the store vector pair instruction. > > This patch does a split after reload to convert a store vector pair > instruction into a pair of store vector instructions. > > We do continue to generate the load vector pair instructions (lxvp, plxvp, > and lxvpx), since we have found that in code that heavily uses MMA, it is > still a win to generate the load vector pair instructions. > > There are two future patches planed: > > 1) Disable block moves from generating load/store vector pair > instructions unless the the store vector pair instructions are > being generted. > > 2) Make the built-in functions for generating store vector pair > always generate those instructions even if store vector pair > instructions are disabled. > > I have built bootstrap compilers and run the regression tests on three > different systems: > > 1) Little endian power10 using the --with-cpu=power10 option. > > 2) Little endian power9 using the --with-cpu=power9 option. > > 3) Big endian power8 using the --with-cpu=power8 option. On this system, > both 64-bit and 32-bit code generation was tested. > > There were no regressions in the runs except for the tests that are > modified in patch #3 in these series of patches. Can I check this patch > into the trunk? If there are no changes needed for the backports, can I > check this code into the active branches after a burn-in period? > > 2022-06-06 Michael Meissner > > gcc/ > > * config/rs6000/mma.md (movoo): Disable generating store vector > pair instructions unless these are enabled by the user. > (movxo): Likewise. > * config/rs6000/rs6000.cc (rs6000_setup_reg_addr_masks): If store > vector pair instructions are disabled, do not allow vector pair > addresses to be indexed. > (rs6000_split_multireg_move): Do not split XOmode stores into two > store vector pair instructions unless store vector pair > instructions are enabled. > * config/rs6000/rs6000.md (isa attribute): Add stxvp attribute. > (enabled attribute): Disable alternative using store vector pair > instructions unless they are enabled. > * config/rs6000/rs6000.opt (-mstore-vector-pair): New option. > > gcc/testsuite/ > > * gcc.target/powerpc/p10-store-vector-pair-1.c: New test. > * gcc.target/powerpc/p10-store-vector-pair-2.c: New test. > --- > gcc/config/rs6000/mma.md | 41 ++++++---- > gcc/config/rs6000/rs6000.cc | 9 +- > gcc/config/rs6000/rs6000.md | 8 +- > gcc/config/rs6000/rs6000.opt | 4 + > .../powerpc/p10-store-vector-pair-1.c | 82 +++++++++++++++++++ > .../powerpc/p10-store-vector-pair-2.c | 81 ++++++++++++++++++ > 6 files changed, 206 insertions(+), 19 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/powerpc/p10-store-vector-pair-1.c > create mode 100644 gcc/testsuite/gcc.target/powerpc/p10-store-vector-pair-2.c > > diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md > index a183b6a168a..9b5f243b88d 100644 > --- a/gcc/config/rs6000/mma.md > +++ b/gcc/config/rs6000/mma.md > @@ -274,26 +274,35 @@ (define_expand "movoo" > DONE; > }) > > +;; By default for power10, do not generate the stxvp/pstxvp/stxvpx > +;; instructions. Instead, split these instructions into two separate store > +;; vector instructions. We do always generate a lxvp/plxvp/lxvpx instruction. > +;; We leave in the support for generating stxvp/pstxvp/stxvpx in future > +;; machines. ... and if (undocumented) STORE_VECTOR_PAIR option is indicated ? Nothing else jumps out at me. Thanks -Will