Message ID | YuIUBVkLjqjYMZhp@toto.the-meissners.org |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:b5d6:b0:2b9:3548:2db5 with SMTP id v22csp39100pxt; Wed, 27 Jul 2022 21:44:40 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vNn6sYrY7Hyq3jSRRwMBVD15KTpeoKAVQVRenwE2pjGWq04osPyEQUAx8bwy2sEXKCZxKc X-Received: by 2002:a05:6402:4444:b0:43b:b8bb:fcc3 with SMTP id o4-20020a056402444400b0043bb8bbfcc3mr26113473edb.305.1658983480397; Wed, 27 Jul 2022 21:44:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658983480; cv=none; d=google.com; s=arc-20160816; b=mqhmJssJLEVYvGtJLy2lq+0stysFiWHCGyk0D6EE/Gev3FReHDFz2NcYsC04WRGfVB JUu/GA4FU8iu2u0+E6oMxiz60/MC9VaW1vML9JCvxVHrKHw7pgQ1ap7GbvVDpM+egOuO d+QWVdCAsg+sZ+k8PTaRlpkeGa47QD5PF6aqD1g/8ypoeDRiu+yZ71Y1gRjdwSKEJfdh oBp6uYuvxC0ZY1NQZLvfosKpgmUk8TuGn3QsTWfLAAXs91OfOjtbGIsJcLM6RMLjCGmM or9Gj0k1bvLoYrjlGQMN8cmSmm4UDDUUGJCmHEEXLyjsLW5zDTUyH1M8FU+SIe4HzjJ7 Jbaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-disposition:mime-version:mail-followup-to:message-id :subject:to:date:dmarc-filter:delivered-to:dkim-signature :dkim-filter; bh=YQbT5AuRfuy2ekUC5JurXvAvqM9Bz9+i2+2c7Fqm9Sg=; b=Tni6XvEPa+ZOE0RB4T2sVp1QxPyDYrFaOG7oZ+P50CE/tSvbowj3ivTu3bVpZPzee1 zx17XW4xclvJ3mWUbAX18xYmkm5904zkcFvSTW1hvbfaLGfWiNs3zrhsjAn9zcKEj6xQ gI7cWLBW0PUaOQNVqIy7xGVGUvy/lgeaINo6Nu3IqTwg8fZT6muDANt2TBcLMo3PSSeQ QZ5pUXzhSLiUKRzTZvhrMGGXPCisZoyUhu4GIL74gmYtqvWnBjAyVKqE8Ezk9A3BiNed A4JQ0NGehva2YA3EXOEXRMB36wJIoU2TQKRQIiEJYyJG3mkFVH7yuvqbT6AVD/NPwilY igCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=pb2Vn3zX; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id sg12-20020a170907a40c00b00718d0604af4si22797251ejc.604.2022.07.27.21.44.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 21:44:40 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=pb2Vn3zX; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3E4963857C40 for <ouuuleilei@gmail.com>; Thu, 28 Jul 2022 04:44:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E4963857C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1658983479; bh=YQbT5AuRfuy2ekUC5JurXvAvqM9Bz9+i2+2c7Fqm9Sg=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=pb2Vn3zXIlLEvUT2l4VjMvbaGA3eFe1RwHmi/tZFX3ChPN8660rfRL5ojLlxTknMh 7Nz5yJwBR/57GJ9N9rFGtFyB5jkqp6FUSwzV4PFA+awFb7CgB+G9ObCD7ajdXtiyQ3 y9pXzaSD8Q0MiJ0M5GNYVphz9avuqECKgZDhki7M= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id A128C385829F for <gcc-patches@gcc.gnu.org>; Thu, 28 Jul 2022 04:43:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A128C385829F Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26S4LUFp028214; Thu, 28 Jul 2022 04:43:53 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hkkc10vu6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jul 2022 04:43:53 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 26S4MAIu031151; Thu, 28 Jul 2022 04:43:52 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hkkc10vtt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jul 2022 04:43:52 +0000 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 26S4KGAj026914; Thu, 28 Jul 2022 04:43:51 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma01wdc.us.ibm.com with ESMTP id 3hg94vwd86-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jul 2022 04:43:51 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26S4hoWI12518084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Jul 2022 04:43:50 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D3009AC059; Thu, 28 Jul 2022 04:43:50 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8AF91AC05B; Thu, 28 Jul 2022 04:43:50 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.225.181]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTPS; Thu, 28 Jul 2022 04:43:50 +0000 (GMT) Date: Thu, 28 Jul 2022 00:43:49 -0400 To: gcc-patches@gcc.gnu.org, Michael Meissner <meissner@linux.ibm.com>, Segher Boessenkool <segher@kernel.crashing.org>, "Kewen.Lin" <linkw@linux.ibm.com>, David Edelsohn <dje.gcc@gmail.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> Subject: [PATCH 0/5] IEEE 128-bit built-in overload support. Message-ID: <YuIUBVkLjqjYMZhp@toto.the-meissners.org> Mail-Followup-To: Michael Meissner <meissner@linux.ibm.com>, gcc-patches@gcc.gnu.org, Segher Boessenkool <segher@kernel.crashing.org>, "Kewen.Lin" <linkw@linux.ibm.com>, David Edelsohn <dje.gcc@gmail.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 9vCcdopADfKqhs2Wvmz8oCi68-E8HklS X-Proofpoint-ORIG-GUID: FVWFxaZ5-lLYXi1nzLBbJOi1WEBykJ09 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-07-27_08,2022-07-27_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 spamscore=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207280019 X-Spam-Status: No, score=-3.7 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Michael Meissner via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Michael Meissner <meissner@linux.ibm.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1739570262217425904?= X-GMAIL-MSGID: =?utf-8?q?1739570262217425904?= |
Series |
IEEE 128-bit built-in overload support.
|
|
Message
Michael Meissner
July 28, 2022, 4:43 a.m. UTC
The following patches add support for doing built-in function overloading between the two 128-bit IEEE types (i.e. _Float182/__float128 using KFmode and when long double uses the IEEE 128-bit encoding with TFmode). 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. But before I can submit those patches to change the internal type structure, I need to make sure that the built-in functions can handle both sets of types, and the overload mechanism automatically switches between the two. There are 5 patches in the series. The first patch adds the infrastructure to the built-in mechanism to deal with long doubles that use the IEEE 128-bit encoding. The second patch adds overload support to the IEEE 128-bit round to odd built-in functions. The third patch adds overload support to the IEEE 128-bit comparason built-in functions. The fourth patch adds overload support to the IEEE 128-bit scalar extract field and insert field built-in functions. The fifth patch adds overload support to the IEEE 128-bit test data and test data negate built-in functions. I have tested these patches on a power10 that is running Fedora 36, which defaults to using long doubles that are IEEE 128-bit. I have built two parallel GCC compilers, one that defaults to using IEEE 128-bit long doubles and one that defaults to using IBM 128-bit long doubles. I have compared the test results to the original compiler results, comparing a modified GCC to the original compiler using an IEEE 128-bit long double default, and also comparing a modified GCC to the original compiler using an IBM 128-bit long double default. In both cases, the results are the same. I have also compared the compilers with the future patch in progress that does switch the internal type handling. Once those patches are installed, the overload mechanism will insure the correct built-in is used. Can I install these patches to the trunk?
Comments
Ping patches. Patch #1 of 5. | Date: Thu, 28 Jul 2022 00:47:13 -0400 | Subject: [PATCH 1/5] IEEE 128-bit built-in overload support. | Message-ID: <YuIU0Yj4mu8LASSd@toto.the-meissners.org> Patch #2 of 5. | Date: Thu, 28 Jul 2022 00:48:51 -0400 | Subject: [PATCH 2/5] Support IEEE 128-bit overload round_to_odd built-in functions. | Message-ID: <YuIVM+APJ5g/Yzcv@toto.the-meissners.org> Patch #3 of 5. | Date: Thu, 28 Jul 2022 00:50:43 -0400 | Subject: [PATCH 3/5] Support IEEE 128-bit overload comparison built-in functions. | Message-ID: <YuIVo7MN5hmUzlOr@toto.the-meissners.org> Patch #4 of 5. | Date: Thu, 28 Jul 2022 00:52:38 -0400 | Subject: [PATCH 4/5] Support IEEE 128-bit overload extract and insert built-in functions. | Message-ID: <YuIWFhnEXlfee42q@toto.the-meissners.org> Patch #5 of 5. | Date: Thu, 28 Jul 2022 00:54:15 -0400 | Subject: [PATCH 5/5] Support IEEE 128-bit overload test data built-in functions. | Message-ID: <YuIWd+k7A3+lf6Hd@toto.the-meissners.org>
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
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.
On Wed, Aug 10, 2022 at 02:23:27AM -0400, Michael Meissner wrote: > 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. > > First of all, it already IS different from KFmode and IFmode, as we've talked > about. It always is the same as either IFmode or KFmode in the end. It is a separate mode, yes, because generic code always wants to use TFmode. > 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 do types have to do with this at all? If TFmode means IEEE QP float, TFmode and KFmode can be used interchangeably. When TFmode means double-double, TFmode and IFmode can be used interchangeably. We should never depend on TFmode being different from both underlying modes, that way madness lies. If you remember, in 2016 or such I experimented with making TFmode a macro-like thingie, so that we always get KFmode and IFmode in the instruction stream. This did not work because of the fundamental problem that KFmode and IFmode cannot be ordered: for both modes there are numbers it can represent that cannot be represented in the other mode; converting from IFmode to KFmode is lossty for some numbers, and the same is true for converting from KFmode to IFmode. But, some internals of GCC require all pairs of floating point modes (that can be converted between at least) to be comparable (in the mathmatical sense). Until that problem is solved, we CANNOT move forward. Your 126/127/128 precision hack gave us some time, but nothing has been improved since then, and things have started to fall apart at the seams again Segher
On Wed, Aug 10, 2022 at 12:03:16PM -0500, Segher Boessenkool wrote: > On Wed, Aug 10, 2022 at 02:23:27AM -0400, Michael Meissner wrote: > > 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. > > > > First of all, it already IS different from KFmode and IFmode, as we've talked > > about. > > It always is the same as either IFmode or KFmode in the end. It is a > separate mode, yes, because generic code always wants to use TFmode. > > > 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 do types have to do with this at all? I believe the issue is with these two tests: gcc.dg/torture/float128-nan.c gcc.target/powerpc/nan128-1.c In particular, both use nansq to create a signaling NaN. The nansq function is defined as nansf128 (i.e. it returns a _Float128 type). However, at present, __float128 uses the long double type if the -mabi=ieeelongdouble option is used, not the _Float128 type. Even though these both use TFmode in that scenario, the gimple code sees a _Float128 type that is stored into a long double type. The machine independent support sees that you are changing types, and it silently converts the signaling NaN into a quiet NaN. An earlier patch was to just change nanq and nansq to resolve to nanl and nansl in the case -mabi=ieeelongdouble, which you did not like. In looking at it, I now believe that the type for _Float128 and __float128 should always be the same within the compiler. Whether we would continue to use the same type for long double and _Float128/__float128 remains to be seen. But in doing the change, there are several places that need to be changed as well. > If TFmode means IEEE QP float, TFmode and KFmode can be used > interchangeably. When TFmode means double-double, TFmode and IFmode can > be used interchangeably. We should never depend on TFmode being > different from both underlying modes, that way madness lies. No, this is not supported without conversions being done (even if the conversions are eventually nop conversions). GCC firmly believes that there are no modes that are equivalant and can be used interchangeably. For example, in the float128-odd.c test case we have: __float128 f128_fms (__float128 a, __float128 b, __float128 c) { return __builtin_fmaf128_round_to_odd (a, b, -c); } by default if we just use the KFmode functions (because that is how they are defined in the built-in tables) on a system where __float128 uses the long double type and uses the TFmode, and remove the code in rs6000_expand_builtin that changes the built-in (i.e. overloading by another name) right now the compiler will trap because it calls copy_to_mode_reg if the predicate fails, and the mode being copied is different from the operand. The predicate fails because the type in the insn (i.e. KFmode) is not the same as the type of the operand (i.e. TFmode), and the default predicate (i.e. register_operand, altivec_register_operand, or vsx_register_operand) checks the mode. But that can be fixed by using convert_move's instead of copy_to_mode_reg, and possibly with new predicates that support either TFmode or KFmode. However, then GCC will insert convert's going from TFmode to KFmode. Which avoids the crash, but the converts mean that the combiner won't combine the negate and __builtin_fmaf128_round_to_od and produce the single "xsmsubqpo" instruction. Instead it will generate a negate and then a "xsmaddqpo" instruction. I've played with adding new predicates that recognize either IEEE 128-bit type and a separate one that recognizes either IBM 128-bit type. This is why I proposed to have overload support so that the built-in functions will automatically use a TFmode built-in or a KFmode built-in depending on what the mode.
On Thu, 11 Aug 2022, Michael Meissner via Gcc-patches wrote: > In looking at it, I now believe that the type for _Float128 and __float128 > should always be the same within the compiler. Whether we would continue to > use the same type for long double and _Float128/__float128 remains to be seen. long double and _Float128 must always be different types; that's how it's defined in C23.
On Thu, Aug 11, 2022 at 08:44:17PM +0000, Joseph Myers wrote: > On Thu, 11 Aug 2022, Michael Meissner via Gcc-patches wrote: > > > In looking at it, I now believe that the type for _Float128 and __float128 > > should always be the same within the compiler. Whether we would continue to > > use the same type for long double and _Float128/__float128 remains to be seen. > > long double and _Float128 must always be different types; that's how it's > defined in C23. And when we implement C++23 P1467R9, if std::float128_t will be _Float128 under the hood, then long double and _Float128 have to remain distinct types and mangle differently, long double (and __float128 if long double is IEEE quad and __float128 exists?) need to mangle the way they currently do and _Float128 should mangle as DF128_ . ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits) Wonder how shall we mangle the underlying type of std::bfloat16_t though. I assume e.g. for libstdc++ implementation purposes we need to have __ibm128 and __float128 types mangling as long double mangles when the -mabi={ibm,ieee}longdouble option is used, because otherwise it would be really hard to implement it. Jakub
Hi! On Tue, Aug 16, 2022 at 08:07:48PM +0200, Jakub Jelinek wrote: > On Thu, Aug 11, 2022 at 08:44:17PM +0000, Joseph Myers wrote: > > On Thu, 11 Aug 2022, Michael Meissner via Gcc-patches wrote: > > > In looking at it, I now believe that the type for _Float128 and __float128 > > > should always be the same within the compiler. Whether we would continue to > > > use the same type for long double and _Float128/__float128 remains to be seen. > > > > long double and _Float128 must always be different types; that's how it's > > defined in C23. > > And when we implement C++23 P1467R9, if std::float128_t will be > _Float128 under the hood, then long double and _Float128 have to remain > distinct types and mangle differently, long double (and __float128 if > long double is IEEE quad and __float128 exists?) need to mangle the way > they currently do and _Float128 should mangle as DF128_ . > ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits) So should we make std::floatNN_t be the same as _FloatNN, and mangled as DF<NN>_ ? And __ieee128 (and long double implemented as that) the same as we already have. > Wonder how shall we mangle the underlying type of std::bfloat16_t though. That should get some cross-platform mangling? Power shouldn't go its own way here :-) > I assume e.g. for libstdc++ implementation purposes we need to have > __ibm128 and __float128 types mangling as long double mangles when the > -mabi={ibm,ieee}longdouble option is used, because otherwise it would be > really hard to implement it. If at all possible it should be the same as we have already: otherwise it will be at least five years before anything works again (for users). This agrees with what you propose afaics, but let's make this explicit? It helps us sleep at night :-) Segher