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 9EBA13858D33 for ; Sat, 7 Jan 2023 00:41:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9EBA13858D33 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 (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 306MjBb3011651; Sat, 7 Jan 2023 00:41:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=PiFfaelM0SgfhB3nCe16Mm3Q78r0b9VGM2iJnyHgY/k=; b=GrG+KS77wqqADAErZG28D/UkpBol/5hx6b/w8QLjYvmwd4wvKVDjzB5OrnptXPM1a7Gu OXEBIv99FveMwcvfRwh6KXSPyGu4QHlweB06LUyT1U+Lh/zKvKkVxFvAkGYt1/ybzAdu Mu9GTQecMhZwSdmf8qyYrOb4iVjEQCyDifjysJWEmlDO5pq1FJAuxtbMUZPNffEFr46H W0N4LS+8kySBHXmILD4p81djIb8NH1U6uI9r0cgaSsvaU1uvfcz57C7xCqErYX3/cGBQ 5AjthBdbcGec+0gAWS+UBHRns2xVTKCeM1IcjjvIF2/jjc1ixzBgYB6oyl0s9tnlVlL1 EA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mxj48eew0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Jan 2023 00:41:13 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3070QKbv000867; Sat, 7 Jan 2023 00:41:12 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mxj48eevm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Jan 2023 00:41:12 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30706UMH020198; Sat, 7 Jan 2023 00:41:11 GMT Received: from smtprelay03.dal12v.mail.ibm.com ([9.208.130.98]) by ppma02dal.us.ibm.com (PPS) with ESMTPS id 3mtcq87stu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Jan 2023 00:41:11 +0000 Received: from smtpav05.dal12v.mail.ibm.com (smtpav05.dal12v.mail.ibm.com [10.241.53.104]) by smtprelay03.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3070fA9L5702338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 7 Jan 2023 00:41:10 GMT Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 19E845804C; Sat, 7 Jan 2023 00:41:10 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6376658056; Sat, 7 Jan 2023 00:41:09 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.42.232]) by smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTPS; Sat, 7 Jan 2023 00:41:09 +0000 (GMT) Date: Fri, 6 Jan 2023 19:41:07 -0500 From: Michael Meissner To: Joseph Myers Cc: Segher Boessenkool , "Kewen.Lin" , GCC Patches , Michael Meissner , David Edelsohn , Jakub Jelinek , Peter Bergner , Richard Biener , Richard Sandiford Subject: Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299] Message-ID: Mail-Followup-To: Michael Meissner , Joseph Myers , Segher Boessenkool , "Kewen.Lin" , GCC Patches , David Edelsohn , Jakub Jelinek , Peter Bergner , Richard Biener , Richard Sandiford References: <718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com> <20221221212407.GU25951@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-GUID: e5c2HKlNXU6V53IYAQwjKry2gjmfeCaX X-Proofpoint-ORIG-GUID: VhvAZWCYV7ZDBpr-Lrb-etR3E_rew-CK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-06_14,2023-01-06_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 clxscore=1015 adultscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301070003 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote: > On Wed, 21 Dec 2022, Segher Boessenkool wrote: > > > > --- a/gcc/tree.cc > > > +++ b/gcc/tree.cc > > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char) > > > if (!targetm.floatn_mode (n, extended).exists (&mode)) > > > continue; > > > int precision = GET_MODE_PRECISION (mode); > > > - /* Work around the rs6000 KFmode having precision 113 not > > > - 128. */ > > > > It has precision 126 now fwiw. > > > > Joseph: what do you think about this patch? Is the workaround it > > removes still useful in any way, do we need to do that some other way if > > we remove this? > > I think it's best for the TYPE_PRECISION, for any type with the binary128 > format, to be 128 (not 126). > > It's necessary that _Float128, _Float64x and long double all have the same > TYPE_PRECISION when they have the same (binary128) format, or at least > that TYPE_PRECISION for _Float128 >= that for long double >= that for > _Float64x, so that the rules in c_common_type apply properly. > > How the TYPE_PRECISION compares to that of __ibm128, or of long double > when that's double-double, is less important. I spent a few days on working on this. I have patches to make the 3 128-bit types to all have TYPE_PRECISION of 128. To do this, I added a new mode macro (FRACTIONAL_FLOAT_MODE_NO_WIDEN) that takes the same arguments as FRACTIONAL_FLOAT_MODE. This will create a floating point mode that is a normal floating point mode, but the GET_MODE_WIDER and GET_MODE_2XWIDER macros will never return it. By declaring both IFmode and KFmode to not be widened to, but noral TFmode is, it eliminates the problems where an IBM expression got converted to IEEE, which can mostly (but not always) contain the value. In addition, on power8, it means it won't call the KF mode emulator functions, just the IF functions. We need to have one 128-bit mode (TFmode) that is not declared as NO_WARN, or long double won't be created, since float_mode_for_size (128) will not be able to find the correct type. I did have to patch convert_mode_scalar so that it would not abort if it was doing a conversion between two floating point types with the same precision. I tested this with the first patch from the previous set of patches (that rewrites complex multiply/divide built-in setup). I think that patch is useful as a stand alone patch. I also used Kewen Lin's patch from December 27th in build_common_tree_nodes to do the test. I haven't tested if this particular patch fixes this problem, or it fixes something else. Finally, I used the third patch in my series of patches that straightens out 128<->128 FP conversions. That patch needed to be tweaked slightly, as one of the conversations became FLOAT_EXTEND instead of FLOAT_TRUNCATE. We don't have a RTL operation that says convert from one floating point type to another where both types are the same size. Whether FLOAT_EXTEND is used or FLOAT_TRUNCATE, used to depend on whether the TYPE_PRECISION was greater or lesser. Now that they are the same, it arbitrarily picks FLOAT_EXTEND. While I still think the 2nd patch is important, it isn't needed with the above patches. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com