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 5BAA03857817 for ; Wed, 8 Sep 2021 22:13:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5BAA03857817 Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 188M4S2N048962; Wed, 8 Sep 2021 18:13:54 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3ay4bb9x4r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Sep 2021 18:13:54 -0400 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 188M5qoK054903; Wed, 8 Sep 2021 18:13:53 -0400 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com with ESMTP id 3ay4bb9x4f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Sep 2021 18:13:53 -0400 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 188M83JW015994; Wed, 8 Sep 2021 22:13:52 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma01wdc.us.ibm.com with ESMTP id 3axcnne9e2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Sep 2021 22:13:52 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 188MDqZI39846252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Sep 2021 22:13:52 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2DC53AC062; Wed, 8 Sep 2021 22:13:52 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C4D8DAC065; Wed, 8 Sep 2021 22:13:51 +0000 (GMT) Received: from [9.65.227.44] (unknown [9.65.227.44]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 8 Sep 2021 22:13:51 +0000 (GMT) To: Segher Boessenkool , David Edelsohn Cc: GCC Patches From: Peter Bergner Subject: [PING][PATCH] rs6000: Disable optimizing multiple xxsetaccz instructions into one xxsetaccz Message-ID: <958f141a-1c30-b10e-cc92-33805221ee89@linux.ibm.com> Date: Wed, 8 Sep 2021 17:13:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-GUID: WzU6vPfgUhUaEvo4mRDqeSBP60nrqz2b X-Proofpoint-ORIG-GUID: _CWedWr5_eb5mygfekURhvtQGLeMS90a Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-08_09:2021-09-07, 2021-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 spamscore=0 bulkscore=0 phishscore=0 clxscore=1015 mlxscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001 definitions=main-2109080137 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 08 Sep 2021 22:14:00 -0000 I'd like to ping the following MMA patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578288.html Message-ID: <8393a33f-50ab-6720-0017-3f012803b990@linux.ibm.com> Peter Fwprop will happily optimize two xxsetaccz instructions into one xxsetaccz by propagating the results of the first to the uses of the second. We really don't want that to happen given the late priming/depriming of accumulators. I fixed this by making the xxsetaccz source operand an unspec volatile. I also removed the mma_xxsetaccz define_expand and define_insn_and_split and replaced it with a simple define_insn. The expand and splitter patterns were leftovers from the pre opaque mode code when the xxsetaccz code was part of the movpxi pattern, and we don't need them now. Rather than a new test case, I was able to just modify the current test case to add another __builtin_mma_xxsetaccz call which shows the bad code gen with unpatched compilers. This passed bootstrap on powerpc64le-linux with no regressions. Ok for trunk? We'll need this for sure in GCC11. Ok there too after some trunk burn in time? GCC10 suffers from the same issue, but since the code is different, I'll have to determine a different solution which I'll post as a separate patch. gcc/ * config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_XXSETACCZ. (unspecv): Add UNSPECV_MMA_XXSETACCZ. (*mma_xxsetaccz): Delete. (mma_xxsetaccz): Change to define_insn. Remove match_operand. Use UNSPECV_MMA_XXSETACCZ. * config/rs6000/rs6000.c (rs6000_rtx_costs): Use UNSPECV_MMA_XXSETACCZ. gcc/testsuite/ * gcc.target/powerpc/mma-builtin-6.c: Add second call to xxsetacc built-in. Update instruction counts.