From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 258873858419 for ; Wed, 10 Aug 2022 06:23:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 258873858419 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27A67ZR9021893; Wed, 10 Aug 2022 06:23:32 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3hv4c6m6jj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Aug 2022 06:23:32 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 27A6Jo7U011874; Wed, 10 Aug 2022 06:23:32 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3hv4c6m6j8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Aug 2022 06:23:32 +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 27A66YIX025738; Wed, 10 Aug 2022 06:23:31 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma04wdc.us.ibm.com with ESMTP id 3huww3tquh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Aug 2022 06:23:31 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27A6NUr341550134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Aug 2022 06:23:30 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5E035136055; Wed, 10 Aug 2022 06:23:30 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D202F13604F; Wed, 10 Aug 2022 06:23:29 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.225.181]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTPS; Wed, 10 Aug 2022 06:23:29 +0000 (GMT) Date: Wed, 10 Aug 2022 02:23:27 -0400 From: Michael Meissner To: Segher Boessenkool Cc: Michael Meissner , gcc-patches@gcc.gnu.org, "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt Subject: Re: [PATCH 0/5] IEEE 128-bit built-in overload support. Message-ID: Mail-Followup-To: Michael Meissner , Segher Boessenkool , gcc-patches@gcc.gnu.org, "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt References: <20220805181905.GQ25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220805181905.GQ25951@gate.crashing.org> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: fW4_e109KG7t9B93lT9XSf342MLsZCSe X-Proofpoint-GUID: 8OrE4VEBVpN1oVh7BVET8K8Fb8tLYuUI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-10_01,2022-08-09_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxlogscore=999 impostorscore=0 bulkscore=0 mlxscore=0 suspectscore=0 phishscore=0 adultscore=0 priorityscore=1501 spamscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208100017 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, 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: Wed, 10 Aug 2022 06:23:36 -0000 On Fri, Aug 05, 2022 at 01:19:05PM -0500, Segher Boessenkool wrote: > On Thu, Jul 28, 2022 at 12:43:49AM -0400, Michael Meissner wrote: > > These patches lay the foundation for a set of follow-on patches that will > > change the internal handling of 128-bit floating point types in GCC. In the > > future patches, I hope to change the compiler to always use KFmode for the > > explicit _Float128/__float128 types, to always use TFmode for the long double > > type, no matter which 128-bit floating point type is used, and IFmode for the > > explicit __ibm128 type. > > Making TFmode different from KFmode and IFmode is not an improvement. > NAK. > > > Segher First of all, it already IS different from KFmode and IFmode, as we've talked about. I'm trying to clean this mess up. Having explicit __float128's being converted to TFmode if -mabi=ieeelongdouble is just as bad, and it means that _Float128 and __float128 are not the same type. What I'm trying to eliminate is the code in rs6000-builtin.cc that overrides the builtin ops (i.e. it does the equivalent of an overloaded function): /* TODO: The following commentary and code is inherited from the original builtin processing code. The commentary is a bit confusing, with the intent being that KFmode is always IEEE-128, IFmode is always IBM double-double, and TFmode is the current long double. The code is confusing in that it converts from KFmode to TFmode pattern names, when the other direction is more intuitive. Try to address this. */ /* We have two different modes (KFmode, TFmode) that are the IEEE 128-bit floating point type, depending on whether long double is the IBM extended double (KFmode) or long double is IEEE 128-bit (TFmode). It is simpler if we only define one variant of the built-in function, and switch the code when defining it, rather than defining two built- ins and using the overload table in rs6000-c.cc to switch between the two. If we don't have the proper assembler, don't do this switch because CODE_FOR_*kf* and CODE_FOR_*tf* will be CODE_FOR_nothing. */ if (FLOAT128_IEEE_P (TFmode)) switch (icode) { case CODE_FOR_sqrtkf2_odd: icode = CODE_FOR_sqrttf2_odd; break; case CODE_FOR_trunckfdf2_odd: icode = CODE_FOR_trunctfdf2_odd; break; case CODE_FOR_addkf3_odd: icode = CODE_FOR_addtf3_odd; break; case CODE_FOR_subkf3_odd: icode = CODE_FOR_subtf3_odd; break; case CODE_FOR_mulkf3_odd: icode = CODE_FOR_multf3_odd; break; case CODE_FOR_divkf3_odd: icode = CODE_FOR_divtf3_odd; break; case CODE_FOR_fmakf4_odd: icode = CODE_FOR_fmatf4_odd; break; case CODE_FOR_xsxexpqp_kf: icode = CODE_FOR_xsxexpqp_tf; break; case CODE_FOR_xsxsigqp_kf: icode = CODE_FOR_xsxsigqp_tf; break; case CODE_FOR_xststdcnegqp_kf: icode = CODE_FOR_xststdcnegqp_tf; break; case CODE_FOR_xsiexpqp_kf: icode = CODE_FOR_xsiexpqp_tf; break; case CODE_FOR_xsiexpqpf_kf: icode = CODE_FOR_xsiexpqpf_tf; break; case CODE_FOR_xststdcqp_kf: icode = CODE_FOR_xststdcqp_tf; break; case CODE_FOR_xscmpexpqp_eq_kf: icode = CODE_FOR_xscmpexpqp_eq_tf; break; case CODE_FOR_xscmpexpqp_lt_kf: icode = CODE_FOR_xscmpexpqp_lt_tf; break; case CODE_FOR_xscmpexpqp_gt_kf: icode = CODE_FOR_xscmpexpqp_gt_tf; break; case CODE_FOR_xscmpexpqp_unordered_kf: icode = CODE_FOR_xscmpexpqp_unordered_tf; break; default: break; } // ... other code if (bif_is_ibm128 (*bifaddr) && TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD) { if (fcode == RS6000_BIF_PACK_IF) { icode = CODE_FOR_packtf; fcode = RS6000_BIF_PACK_TF; uns_fcode = (size_t) fcode; } else if (fcode == RS6000_BIF_UNPACK_IF) { icode = CODE_FOR_unpacktf; fcode = RS6000_BIF_UNPACK_TF; uns_fcode = (size_t) fcode; } } In particular, without overloaded built-ins, we likely have something similar to the above to cover all of the built-ins for both modes. I tend to think overloading is more natural in this case. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com