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 6637A3858D39 for ; Wed, 1 Feb 2023 03:31:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6637A3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3112hKCp030928; Wed, 1 Feb 2023 03:31:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=4C+f/antAzJxMIju3tfOOgt6SgViK/7XCc+qMfVj8DQ=; b=AHVhT783hDo1FsFCG7TXJHP8IJ1U+0LgUoly7+SkhKHXqKZHAw8YnvQlkUA83/G8jJoP r04scdlYr9Yz8Xos+MAOvpMqo6AEh7KXAdm27sQPf3f3PME6vM/PajvI7TqteS78X/xz 0rBGtA5ArePMAMKfGgDoBT1I7u4FBRlszGl4WzoMvCk2YYNZ/t6RcG3J+APcpF7s04eF 834FJxpBYvrIdVoebtbzg4PqEwZ27zpq3fwXZnItC0ajCwRHiwdNImUrVNflE/pq8WRT 8FgfX9nJP59K06zzNot0PuwHLyKr1yGNJirCPzj/q1JLS+I/3t70xm+09c7VbTpaw3yT rw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nf83dc5yx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Feb 2023 03:31:07 +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 311362w1016840; Wed, 1 Feb 2023 03:31:07 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nf83dc5yk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Feb 2023 03:31:07 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3112oGbu012321; Wed, 1 Feb 2023 03:31:06 GMT Received: from smtprelay04.dal12v.mail.ibm.com ([9.208.130.102]) by ppma05wdc.us.ibm.com (PPS) with ESMTPS id 3ncvvdkg8t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Feb 2023 03:31:06 +0000 Received: from smtpav04.dal12v.mail.ibm.com (smtpav04.dal12v.mail.ibm.com [10.241.53.103]) by smtprelay04.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3113V5vj56557846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Feb 2023 03:31:05 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8EB525804E; Wed, 1 Feb 2023 03:31:05 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0B1C358052; Wed, 1 Feb 2023 03:31:05 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.233.34]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTPS; Wed, 1 Feb 2023 03:31:04 +0000 (GMT) Date: Tue, 31 Jan 2023 22:31:03 -0500 From: Michael Meissner To: Michael Meissner , Segher Boessenkool , gcc-patches@gcc.gnu.org, "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt Subject: Re: [PATCH 0/6] PowerPC Dense Math prelimary support (-mcpu=future) Message-ID: Mail-Followup-To: Michael Meissner , Segher Boessenkool , gcc-patches@gcc.gnu.org, "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt References: <20230127195900.GS25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: l5lfjMHJZ5Nz_ON8YdZPabZI0KkAwt5V X-Proofpoint-GUID: ueOezmscvqVGuQClc3-gCtv_gF7fVAvT X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-31_08,2023-01-31_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 priorityscore=1501 adultscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302010023 X-Spam-Status: No, score=-3.6 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 autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, Jan 29, 2023 at 09:52:38PM -0500, Michael Meissner wrote: > On Sat, Jan 28, 2023 at 02:29:04AM -0500, Michael Meissner wrote: > > On Fri, Jan 27, 2023 at 01:59:00PM -0600, Segher Boessenkool wrote: > > > > There is one bug that I noticed. When you use the full DMR instruction the > > > > constant copy propagation patch issues internal errors. I believe this is due > > > > to the CCP pass not handling opaque types cleanly enough, and it only shows up > > > > in larger types. I would like to get these patches committed, and then work > > > > the maintainers of the CCP to fix the problem. > > > > > > Erm. If the compiler ICEs, we can not include this code. But hopefully > > > you mean something else? > > > > I realize we can't include the code for final release. But as a temporary > > measure I was hoping we would put in the code, we could allow somebody more > > familar with ccp to debug it. Then if there were changes needed in the PowerPC > > back end, we could make them, once ccp was fixed. > > > > But that is a moot point, ccp no longer dies with the code, so I have removed > > the comment and the no tree ccp option in the next set of patches. > > Unfortunately, while it worked on my x86 as a cross compiler, when I did the > builds for real, it is a problem, so I will need to look into it. Ok, I tracked down the source of the bug. The CCP pass is depending on the precision field. Unfortunately in tree-core.h, the precision is a 10 integer bit field, so 1,024 will become 0. Having a 0 precision meant that the hwint function for sign extending a value would generate: (HOST_WIDE_INT)(((unsigned HOST_WIDE_INT)value << 64) >> 64) which is undefined behavior in C and C++. On the x86_64 doing the shift left and then right gives you the initial value (which was -1), while on the PowerPC it always gives you 0. The CCP code was assuming if it wasn't -1, that it was an integer, but the TDO type is opaque, not integer. The solution was to grow precision by 1 bit and decrease the extra bits in the placeholder entry by 1 bit. I'm testing it now. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com