Message ID | e66cfc44-22c1-072d-0af2-b9fe585012a9@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 707323A2A905 for <patchwork@sourceware.org>; Mon, 19 Dec 2022 08:29:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 707323A2A905 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1671438572; bh=h9untzJb3xJZ4aH4kcqYb00P3yd+U8wquyxteGvhrow=; h=Date:Subject:To:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=dQlBSOGH/IUc3P5MtxAsVPauCoW36FO3sSL+cxtZkJH42/Jc0ygnv40I/4f9BhikH 8Nrrd2J+UkdkySvRaXjVZZ+GquLX9Wy8qCtnB4cccQdzS10CvrzAlN5bOTHzVR0j4F zYS1Tid1M3ovfKnmG8DBUZbmGtPX8xa0EMeOPjGI= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 052AC3D9F31B for <gcc-patches@gcc.gnu.org>; Mon, 19 Dec 2022 08:12:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 052AC3D9F31B Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BJ7jreS021934; Mon, 19 Dec 2022 08:12:10 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mjkuurt8m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 08:12:10 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BJ7kA9r022543; Mon, 19 Dec 2022 08:12:09 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mjkuurt6r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 08:12:09 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BJ2O5K7025317; Mon, 19 Dec 2022 08:12:07 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma04ams.nl.ibm.com (PPS) with ESMTPS id 3mh6ywj2wm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 08:12:07 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BJ8C3NF35586452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Dec 2022 08:12:04 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 673952004B; Mon, 19 Dec 2022 08:12:03 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E95B720040; Mon, 19 Dec 2022 08:12:00 +0000 (GMT) Received: from [9.197.234.5] (unknown [9.197.234.5]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 19 Dec 2022 08:12:00 +0000 (GMT) Message-ID: <e66cfc44-22c1-072d-0af2-b9fe585012a9@linux.ibm.com> Date: Mon, 19 Dec 2022 16:11:59 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US Subject: [PATCH] fold-const: Treat fp conversion to a type with same mode as copy To: GCC Patches <gcc-patches@gcc.gnu.org> Cc: Richard Biener <richard.guenther@gmail.com>, Segher Boessenkool <segher@kernel.crashing.org>, Jakub Jelinek <jakub@redhat.com>, Joseph Myers <joseph@codesourcery.com>, Michael Meissner <meissner@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: YhOqTd7VoU4OlNXYWNwKvzQ58MymOPN4 X-Proofpoint-GUID: 8q0llqZ5EIMME9mXLoxL97r1RUbR_PpH Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 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=2022-12-18_13,2022-12-15_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 suspectscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 phishscore=0 mlxlogscore=999 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212190070 X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H2, 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 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: "Kewen.Lin via Gcc-patches" <gcc-patches@gcc.gnu.org> Reply-To: "Kewen.Lin" <linkw@linux.ibm.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
fold-const: Treat fp conversion to a type with same mode as copy
|
|
Commit Message
Kewen.Lin
Dec. 19, 2022, 8:11 a.m. UTC
Hi, In function fold_convert_const_real_from_real, when the modes of two types involved in fp conversion are the same, we can simply take it as copy, rebuild with the exactly same TREE_REAL_CST and the target type. It is more efficient and helps to avoid possible unexpected signalling bit clearing in [1]. Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu and powerpc64{,le}-linux-gnu. Is it ok for trunk? [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608533.html gcc/ChangeLog: * fold-const.cc (fold_convert_const_real_from_real): Treat floating point conversion to a type with same mode as copy instead of normal convertFormat. --- gcc/fold-const.cc | 9 +++++++++ 1 file changed, 9 insertions(+) -- 2.27.0
Comments
On Mon, Dec 19, 2022 at 9:12 AM Kewen.Lin <linkw@linux.ibm.com> wrote: > > Hi, > > In function fold_convert_const_real_from_real, when the modes of > two types involved in fp conversion are the same, we can simply > take it as copy, rebuild with the exactly same TREE_REAL_CST and > the target type. It is more efficient and helps to avoid possible > unexpected signalling bit clearing in [1]. > > Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu > and powerpc64{,le}-linux-gnu. > > Is it ok for trunk? But shouldn't double x = (double) __builtin_nans("sNAN"); result in a quiet NaN? > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608533.html > > gcc/ChangeLog: > > * fold-const.cc (fold_convert_const_real_from_real): Treat floating > point conversion to a type with same mode as copy instead of normal > convertFormat. > --- > gcc/fold-const.cc | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc > index 114258fa182..eb4b6ca8820 100644 > --- a/gcc/fold-const.cc > +++ b/gcc/fold-const.cc > @@ -2178,6 +2178,15 @@ fold_convert_const_real_from_real (tree type, const_tree arg1) > REAL_VALUE_TYPE value; > tree t; > > + /* If the underlying modes are the same, simply treat it as > + copy and rebuild with TREE_REAL_CST information and the > + given type. */ > + if (TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (arg1))) > + { > + t = build_real (type, TREE_REAL_CST (arg1)); > + return t; > + } > + > /* Don't perform the operation if flag_signaling_nans is on > and the operand is a signaling NaN. */ > if (HONOR_SNANS (arg1) > -- > 2.27.0
Hi Richi, Thanks for the comments! on 2022/12/19 16:49, Richard Biener wrote: > On Mon, Dec 19, 2022 at 9:12 AM Kewen.Lin <linkw@linux.ibm.com> wrote: >> >> Hi, >> >> In function fold_convert_const_real_from_real, when the modes of >> two types involved in fp conversion are the same, we can simply >> take it as copy, rebuild with the exactly same TREE_REAL_CST and >> the target type. It is more efficient and helps to avoid possible >> unexpected signalling bit clearing in [1]. >> >> Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu >> and powerpc64{,le}-linux-gnu. >> >> Is it ok for trunk? > > But shouldn't > > double x = (double) __builtin_nans("sNAN"); > > result in a quiet NaN? IMHO, this treatment is still an tiny enhancement even without the consideration on signalling nan. I had the same doubt on if the bif should return qNaN without the explicit option -fsignaling-nans, by checking the manual it says "Compile code assuming that IEEE signaling NaNs may generate user-visible traps during floating-point operations." for the default -fno-signaling-nans, it doesn't exclude sNaN existence clearly, and the generation of sNaN seems not to be like a normal floating point operation which can cause trap. So I was inclined to believe that the current behavior is expected. Besides the glibc uses this built-in for SNAN macro, it seems not a good idea to return a qNaN for it at some cases. BR, Kewen > >> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608533.html >> >> gcc/ChangeLog: >> >> * fold-const.cc (fold_convert_const_real_from_real): Treat floating >> point conversion to a type with same mode as copy instead of normal >> convertFormat. >> --- >> gcc/fold-const.cc | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc >> index 114258fa182..eb4b6ca8820 100644 >> --- a/gcc/fold-const.cc >> +++ b/gcc/fold-const.cc >> @@ -2178,6 +2178,15 @@ fold_convert_const_real_from_real (tree type, const_tree arg1) >> REAL_VALUE_TYPE value; >> tree t; >> >> + /* If the underlying modes are the same, simply treat it as >> + copy and rebuild with TREE_REAL_CST information and the >> + given type. */ >> + if (TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (arg1))) >> + { >> + t = build_real (type, TREE_REAL_CST (arg1)); >> + return t; >> + } >> + >> /* Don't perform the operation if flag_signaling_nans is on >> and the operand is a signaling NaN. */ >> if (HONOR_SNANS (arg1) >> -- >> 2.27.0
On Mon, Dec 19, 2022 at 09:49:36AM +0100, Richard Biener wrote: > On Mon, Dec 19, 2022 at 9:12 AM Kewen.Lin <linkw@linux.ibm.com> wrote: > > In function fold_convert_const_real_from_real, when the modes of > > two types involved in fp conversion are the same, we can simply > > take it as copy, rebuild with the exactly same TREE_REAL_CST and > > the target type. It is more efficient and helps to avoid possible > > unexpected signalling bit clearing in [1]. > > > > Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu > > and powerpc64{,le}-linux-gnu. > > > > Is it ok for trunk? > > But shouldn't > > double x = (double) __builtin_nans("sNAN"); > > result in a quiet NaN? I think it doesn't already, fold_convert_const starts with tree arg_type = TREE_TYPE (arg1); if (arg_type == type) return arg1; and so if it is a conversion to the same type, fold_convert_const_real_from_real won't be called at all. It is just cast to a different type with same mode (say typedef double doublet) that triggers it right now. Try: double foo (void) { return __builtin_nans (""); } double bar (void) { return (double) __builtin_nans (""); } typedef double doublet; doublet baz (void) { return __builtin_nans (""); } doublet qux (void) { return (doublet) __builtin_nans (""); } float corge (void) { return (float) __builtin_nans (""); } GCC right now returns a sNaN in foo and bar and qNaN in baz, qux and corge, clang and ICC (tried 19.0.1 on godbolt) return sNaN in foo, bar, baz, qux and qNaN in corge. The last case is required by C: convertFormat - different formats cast and implicit conversions 6.3.1.5, 6.5.4 convertFormat - same format canonicalize 7.12.11.7, F.10.8.7 As for the rest, C n3047.pdf has: Whether C assignment (6.5.16) (and conversion as if by assignment) to the same format is an IEC 60559 convertFormat or copy operation439) is implementation-defined, even if <fenv.h> defines the macro FE_SNANS_ALWAYS_SIGNAL (F.2.1). If the return expression of a return statement is evaluated to the floating-point format of the return type, it is implementation-defined whether a convertFormat operation is applied to the result of the return expression. 439) Where the source and destination formats are the same, convertFormat operations differ from copy operations in that convertFormat operations raise the "invalid" floating-point exception on signaling NaN inputs and do not propagate non-canonical encodings. I think the posted patch is good for consistency, treating conversion to the same format sometimes as convertFormat and sometimes as copy is maybe valid but confusing, especially when on: double foo (double x) { return x; } double bar (double x) { return (double) x; } typedef double doublet; doublet baz (double x) { return x; } doublet qux (double x) { return (doublet) x; } float corge (double x) { return (float) x; } we actually use copy operations in all of foo, bar, baz and qux. Jakub
Hi! On Mon, Dec 19, 2022 at 11:02:30AM +0100, Jakub Jelinek wrote: > On Mon, Dec 19, 2022 at 09:49:36AM +0100, Richard Biener wrote: > > On Mon, Dec 19, 2022 at 9:12 AM Kewen.Lin <linkw@linux.ibm.com> wrote: > > > In function fold_convert_const_real_from_real, when the modes of > > > two types involved in fp conversion are the same, we can simply > > > take it as copy, rebuild with the exactly same TREE_REAL_CST and > > > the target type. It is more efficient and helps to avoid possible > > > unexpected signalling bit clearing in [1]. > > > > > > Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu > > > and powerpc64{,le}-linux-gnu. > > > > > > Is it ok for trunk? > > > > But shouldn't > > > > double x = (double) __builtin_nans("sNAN"); > > > > result in a quiet NaN? No, it is no conversion, it is a no-op? With -fno-signaling-nans, anything goes. With -fsignaling-nans, only corge should return a qNaN *and trap*, and it does that for me, too (it does an frsp insn on the datum, and that has that effect). With signalling NaNs your program should always trap when it converts a SNaN to a QNaN. Not all operations on SNaNs can be optimised away; any SNaN that is operated on should remain trapping. With -fsignaling-nans very many floating point operations can not be optimised very much. > GCC right now returns a sNaN in foo and bar and qNaN in baz, qux and corge, > clang and ICC (tried 19.0.1 on godbolt) return sNaN in foo, bar, baz, qux > and qNaN in corge. I just get an lfd everywhere (so returns SNaN, doesn't trap) except in corge(), which also does an frsp (round to SP float, so it returns a QNaN, but traps first). > As for the rest, C n3047.pdf has: > Whether C assignment (6.5.16) (and conversion as if by assignment) to the same format is an > IEC 60559 convertFormat or copy operation439) is implementation-defined, even if <fenv.h> defines > the macro FE_SNANS_ALWAYS_SIGNAL (F.2.1). And GCC just does a copy, already? At -O2 anyway. > I think the posted patch is good for consistency, treating conversion to the > same format sometimes as convertFormat and sometimes as copy is maybe valid > but confusing, especially when on: Agreed. Segher
On Mon, Dec 19, 2022 at 04:11:59PM +0800, Kewen.Lin wrote: > In function fold_convert_const_real_from_real, when the modes of > two types involved in fp conversion are the same, we can simply > take it as copy, rebuild with the exactly same TREE_REAL_CST and > the target type. It is more efficient and helps to avoid possible > unexpected signalling bit clearing in [1]. > > Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu > and powerpc64{,le}-linux-gnu. > > Is it ok for trunk? > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608533.html > > gcc/ChangeLog: > > * fold-const.cc (fold_convert_const_real_from_real): Treat floating > point conversion to a type with same mode as copy instead of normal > convertFormat. The patch is ok for trunk. Thanks. Jakub
on 2022/12/20 20:14, Jakub Jelinek wrote: > On Mon, Dec 19, 2022 at 04:11:59PM +0800, Kewen.Lin wrote: >> In function fold_convert_const_real_from_real, when the modes of >> two types involved in fp conversion are the same, we can simply >> take it as copy, rebuild with the exactly same TREE_REAL_CST and >> the target type. It is more efficient and helps to avoid possible >> unexpected signalling bit clearing in [1]. >> >> Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu >> and powerpc64{,le}-linux-gnu. >> >> Is it ok for trunk? >> >> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608533.html >> >> gcc/ChangeLog: >> >> * fold-const.cc (fold_convert_const_real_from_real): Treat floating >> point conversion to a type with same mode as copy instead of normal >> convertFormat. > > The patch is ok for trunk. Thanks. > Thanks! Committed in r13-4815-g94cf7a2d95bf6d. BR, Kewen
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index 114258fa182..eb4b6ca8820 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -2178,6 +2178,15 @@ fold_convert_const_real_from_real (tree type, const_tree arg1) REAL_VALUE_TYPE value; tree t; + /* If the underlying modes are the same, simply treat it as + copy and rebuild with TREE_REAL_CST information and the + given type. */ + if (TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (arg1))) + { + t = build_real (type, TREE_REAL_CST (arg1)); + return t; + } + /* Don't perform the operation if flag_signaling_nans is on and the operand is a signaling NaN. */ if (HONOR_SNANS (arg1)