From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 8BD82386F0C1 for ; Tue, 7 Jun 2022 00:53:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BD82386F0C1 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 256NFcql005815; Tue, 7 Jun 2022 00:53:53 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ghu3m96c2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 00:53:52 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2570ZRJW030767; Tue, 7 Jun 2022 00:53:52 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 3ghu3m96bw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 00:53:52 +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 2570pHNN028253; Tue, 7 Jun 2022 00:53:51 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma04wdc.us.ibm.com with ESMTP id 3gfy19gxsk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 00:53:51 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2570rplZ24510780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jun 2022 00:53:51 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 05E78AE066; Tue, 7 Jun 2022 00:53:51 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B6929AE067; Tue, 7 Jun 2022 00:53:50 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.87.14]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTPS; Tue, 7 Jun 2022 00:53:50 +0000 (GMT) Date: Mon, 6 Jun 2022 20:53:10 -0400 From: Michael Meissner To: gcc-patches@gcc.gnu.org, Michael Meissner , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt Subject: [PATCH, 0/3] Disable generating store vector pair. Message-ID: Mail-Followup-To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-GUID: _QKlgLBVRN-RCKhkvpMVKTjBrK8jnj5E X-Proofpoint-ORIG-GUID: _hO4S6rXkAeF1SRUwS0Ju1KBu-n8y24_ 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-06_07,2022-06-03_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 phishscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 impostorscore=0 spamscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206070000 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_MANYTO, 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 00:53:56 -0000 [PATCH 0/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 (-mstore-vector-pair) 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 3 patches in this set: 1) Disable the generation of the stxvp, stxvpx, and pstxvp instructions for stores of OOmode and XOmodes. 2) Disable block moves from generating load/store vector pair instructions unless the the store vector pair instructions are being generted. With patch #1 installed, the block move code will generate a load vector pair and store vector pair combination, but after reload, the store vector pair instructions are split into two separate store vector instructions. 2) Fix up the mma test suite to deal with store vector pair not being generated by default. In most of the tests, I just deleted the lines that counted the store vector pair instructions. In a few of the tests, I explicitly passed the -mstore-vector-pair instruction since the point of the test was to generate store vector pair instructions. There is a 4th patch that Peter Bergner will be developing. This patch will update the built-in functions for load and store vector pair, so that these built-ins will always generate the lxvp and stxvp instructions. 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. Once all 3 patches have been applied, there are no regressions in the runs. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com