Message ID | 20220829204439.1749727-1-aldyh@redhat.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:ecc5:0:0:0:0:0 with SMTP id s5csp1580789wro; Mon, 29 Aug 2022 13:45:35 -0700 (PDT) X-Google-Smtp-Source: AA6agR5ImsGBqXJqnSECHp3p99WCMq6hDWdIzjYd9xQpVQKVVcRz4jspt6LRazljMQ3Xq5t0LfTI X-Received: by 2002:a17:907:7205:b0:739:1735:8b9a with SMTP id dr5-20020a170907720500b0073917358b9amr14520154ejc.244.1661805935294; Mon, 29 Aug 2022 13:45:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661805935; cv=none; d=google.com; s=arc-20160816; b=X1+qPtJ0vuydTRcTxgulSWfjCimQaNXdhQiCGvbkOQCU/UvC7XdWcfPD6daCrpcB3E 3qvzMwHDy2Q1Hb7yGWU3ch9JD1LZvZ6HsLtW1e/nrjWCCr8zwtKb2EAvQZZfy/Pz6/9c fjF78uhilA4TXQDD/NJRj85KFpsG6byt4ihQBOpjFduQHrGhF8q4VY17BCl9NnUWVOb+ HvLXNbEBCvLIzMV9KYExBcURLeWFurs5+VJKuE0JGbtyC+zj7l/BcK/XUasYQAanAsPk 8DT8ZQ/b1bvhxzfPaJG8q+FUJp9SUtxvypif6O+eXez+0QPSJHGO2w4JjrQSxDyuzt95 DrRA== 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-transfer-encoding:mime-version:message-id:date:subject:to :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=R+HYMM6T4b73rde2LQ9KH8rmPmeHdLIXDWYXNFWzrDA=; b=HwazjR3/fZ/Fa12080AMS2i4BkMUKFNynWAI0RbVYw6S8KmWfKN3aPXiCpPVdjU8G2 wYCVZEZVoDnVSNOPjdmMfDuQTNzbheA7WVf0CbIWx83liOhlw1tZNOWlgzOC5XpROcxS WckXT1yKhM2pmdo+2rcZZFT2FwQz7yH9XMJeQObgqAiErcNyS/oVXcb0ZaLRKJfjHiyT tdKFYDDhRdqLg+CbRB6l17+21R/d1eRGRfe8V9+NlPvOOdOlYA5x137wBqffith13WD0 NWPJNGoquOKaB4JAA7+niEcXZWc6yI+L65f0yJwP1HPjiEIrcFUcJ5V28quaI064dAio EOQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=BXaUk+8L; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c 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 (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id eb9-20020a0564020d0900b004359f471717si9187411edb.0.2022.08.29.13.45.35 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Aug 2022 13:45:35 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=BXaUk+8L; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c 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 CD5C63856DE7 for <ouuuleilei@gmail.com>; Mon, 29 Aug 2022 20:45:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD5C63856DE7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1661805932; bh=R+HYMM6T4b73rde2LQ9KH8rmPmeHdLIXDWYXNFWzrDA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=BXaUk+8L2Pv2IHU8Q3hxP7v9Rk5z8OgFXCVEsDddOF3IaZm9anTDAKaOhuPR/1owa pJxcTj5we3Z9/v+NoPIuwJhgPZ0buanUDPXg3YIUhYXK/4OpqOgvjcgmbPVNxQqCqS /imr6Li96/LflNTij9yJkt/3egsk+72+SEx7/AEo= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0F351385AC3F for <gcc-patches@gcc.gnu.org>; Mon, 29 Aug 2022 20:44:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F351385AC3F Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-557-_33jBQzvNVGkyeFH3M5cVw-1; Mon, 29 Aug 2022 16:44:45 -0400 X-MC-Unique: _33jBQzvNVGkyeFH3M5cVw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9878A85A589 for <gcc-patches@gcc.gnu.org>; Mon, 29 Aug 2022 20:44:45 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.192.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4DC9E2026D4C; Mon, 29 Aug 2022 20:44:45 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.17.1/8.17.1) with ESMTPS id 27TKig5d1749742 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 29 Aug 2022 22:44:42 +0200 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 27TKigdr1749741; Mon, 29 Aug 2022 22:44:42 +0200 To: GCC patches <gcc-patches@gcc.gnu.org> Subject: [PATCH] A == 0 ? A : -A same as -A (when A is 0.0) Date: Mon, 29 Aug 2022 22:44:39 +0200 Message-Id: <20220829204439.1749727-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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 <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: Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Aldy Hernandez <aldyh@redhat.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?1742529820695758117?= X-GMAIL-MSGID: =?utf-8?q?1742529820695758117?= |
Series |
A == 0 ? A : -A same as -A (when A is 0.0)
|
|
Commit Message
Aldy Hernandez
Aug. 29, 2022, 8:44 p.m. UTC
The upcoming work for frange triggers a regression in gcc.dg/tree-ssa/phi-opt-24.c. For -O2 -fno-signed-zeros, we fail to transform the following into -A: float f0(float A) { // A == 0? A : -A same as -A if (A == 0) return A; return -A; } This is because the abs/negative match.pd pattern here: /* abs/negative simplifications moved from fold_cond_expr_with_comparison, Need to handle (A - B) case as fold_cond_expr_with_comparison does. Need to handle UN* comparisons. ... ... Sees IL that has the 0.0 propagated. Instead of: <bb 2> [local count: 1073741824]: if (A_2(D) == 0.0) goto <bb 4>; [34.00%] else goto <bb 3>; [66.00%] <bb 3> [local count: 708669601]: _3 = -A_2(D); <bb 4> [local count: 1073741824]: # _1 = PHI <A_2(D)(2), _3(3)> It now sees: <bb 4> [local count: 1073741824]: # _1 = PHI <0.0(2), _3(3)> which it leaves untouched, causing the if conditional to survive. Adding a variant to the pattern that for real_zerop fixes the problem. I am a match.pd weenie, and am avoiding touching more patterns that may also benefit from handling real constants. So please use simple words if what I'm doing isn't correct ;-). I did not include a testcase, as it's just phi-opt-24.c which will get triggered when I commit the frange with endpoints work. Tested on x86-64 & ppc64le Linux. OK? gcc/ChangeLog: * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant for real zero. --- gcc/match.pd | 4 ++++ 1 file changed, 4 insertions(+)
Comments
On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > The upcoming work for frange triggers a regression in > gcc.dg/tree-ssa/phi-opt-24.c. > > For -O2 -fno-signed-zeros, we fail to transform the following into -A: > > float f0(float A) > { > // A == 0? A : -A same as -A > if (A == 0) return A; > return -A; > } > > This is because the abs/negative match.pd pattern here: > > /* abs/negative simplifications moved from fold_cond_expr_with_comparison, > Need to handle (A - B) case as fold_cond_expr_with_comparison does. > Need to handle UN* comparisons. > ... > ... > > Sees IL that has the 0.0 propagated. > > Instead of: > > <bb 2> [local count: 1073741824]: > if (A_2(D) == 0.0) > goto <bb 4>; [34.00%] > else > goto <bb 3>; [66.00%] > > <bb 3> [local count: 708669601]: > _3 = -A_2(D); > > <bb 4> [local count: 1073741824]: > # _1 = PHI <A_2(D)(2), _3(3)> > > It now sees: > > <bb 4> [local count: 1073741824]: > # _1 = PHI <0.0(2), _3(3)> > > which it leaves untouched, causing the if conditional to survive. > > Adding a variant to the pattern that for real_zerop fixes the problem. > > I am a match.pd weenie, and am avoiding touching more patterns that > may also benefit from handling real constants. So please use simple > words if what I'm doing isn't correct ;-). > > I did not include a testcase, as it's just phi-opt-24.c which will get > triggered when I commit the frange with endpoints work. > > Tested on x86-64 & ppc64le Linux. > > OK? > > gcc/ChangeLog: > > * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant > for real zero. > --- > gcc/match.pd | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gcc/match.pd b/gcc/match.pd > index 1bb936fc401..5bdea300f94 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -4803,6 +4803,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > (cnd (cmp @0 zerop) @0 (negate@1 @0)) > (if (!HONOR_SIGNED_ZEROS (type)) > @1)) > + (simplify > + (cnd (cmp @0 zerop) real_zerop (negate@1 @0)) > + (if (!HONOR_SIGNED_ZEROS (type)) > + @1)) > (simplify > (cnd (cmp @0 zerop) integer_zerop (negate@1 @0)) > (if (!HONOR_SIGNED_ZEROS (type)) Looking at zerop: bool zerop (const_tree expr) { return (integer_zerop (expr) || real_zerop (expr) || fixed_zerop (expr)); } your patch is equivalent to changing the integer_zerop one to use zerop? (well, with the exception of also covering fixed_zerop). OK if doing it that way. Thanks, Richard. > -- > 2.37.1 >
On Tue, Aug 30, 2022 at 9:03 AM Richard Biener <richard.guenther@gmail.com> wrote: > > On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > The upcoming work for frange triggers a regression in > > gcc.dg/tree-ssa/phi-opt-24.c. > > > > For -O2 -fno-signed-zeros, we fail to transform the following into -A: > > > > float f0(float A) > > { > > // A == 0? A : -A same as -A > > if (A == 0) return A; > > return -A; > > } > > > > This is because the abs/negative match.pd pattern here: > > > > /* abs/negative simplifications moved from fold_cond_expr_with_comparison, > > Need to handle (A - B) case as fold_cond_expr_with_comparison does. > > Need to handle UN* comparisons. > > ... > > ... > > > > Sees IL that has the 0.0 propagated. > > > > Instead of: > > > > <bb 2> [local count: 1073741824]: > > if (A_2(D) == 0.0) > > goto <bb 4>; [34.00%] > > else > > goto <bb 3>; [66.00%] > > > > <bb 3> [local count: 708669601]: > > _3 = -A_2(D); > > > > <bb 4> [local count: 1073741824]: > > # _1 = PHI <A_2(D)(2), _3(3)> > > > > It now sees: > > > > <bb 4> [local count: 1073741824]: > > # _1 = PHI <0.0(2), _3(3)> > > > > which it leaves untouched, causing the if conditional to survive. > > > > Adding a variant to the pattern that for real_zerop fixes the problem. > > > > I am a match.pd weenie, and am avoiding touching more patterns that > > may also benefit from handling real constants. So please use simple > > words if what I'm doing isn't correct ;-). > > > > I did not include a testcase, as it's just phi-opt-24.c which will get > > triggered when I commit the frange with endpoints work. > > > > Tested on x86-64 & ppc64le Linux. > > > > OK? > > > > gcc/ChangeLog: > > > > * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant > > for real zero. > > --- > > gcc/match.pd | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/gcc/match.pd b/gcc/match.pd > > index 1bb936fc401..5bdea300f94 100644 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -4803,6 +4803,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > (cnd (cmp @0 zerop) @0 (negate@1 @0)) > > (if (!HONOR_SIGNED_ZEROS (type)) > > @1)) > > + (simplify > > + (cnd (cmp @0 zerop) real_zerop (negate@1 @0)) > > + (if (!HONOR_SIGNED_ZEROS (type)) > > + @1)) > > (simplify > > (cnd (cmp @0 zerop) integer_zerop (negate@1 @0)) > > (if (!HONOR_SIGNED_ZEROS (type)) > > Looking at zerop: > > bool > zerop (const_tree expr) > { > return (integer_zerop (expr) > || real_zerop (expr) > || fixed_zerop (expr)); > } > > your patch is equivalent to changing the integer_zerop one to use zerop? > (well, with the exception of also covering fixed_zerop). Heh. That was my first instinct, but I thought fixed_zerop didn't apply? No clue...I'm happy to change it. Thanks. Aldy > > OK if doing it that way. > > Thanks, > Richard. > > > -- > > 2.37.1 > > >
On Tue, Aug 30, 2022 at 9:07 AM Aldy Hernandez <aldyh@redhat.com> wrote: > > On Tue, Aug 30, 2022 at 9:03 AM Richard Biener > <richard.guenther@gmail.com> wrote: > > > > On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > > > > > > The upcoming work for frange triggers a regression in > > > gcc.dg/tree-ssa/phi-opt-24.c. > > > > > > For -O2 -fno-signed-zeros, we fail to transform the following into -A: > > > > > > float f0(float A) > > > { > > > // A == 0? A : -A same as -A > > > if (A == 0) return A; > > > return -A; > > > } > > > > > > This is because the abs/negative match.pd pattern here: > > > > > > /* abs/negative simplifications moved from fold_cond_expr_with_comparison, > > > Need to handle (A - B) case as fold_cond_expr_with_comparison does. > > > Need to handle UN* comparisons. > > > ... > > > ... > > > > > > Sees IL that has the 0.0 propagated. > > > > > > Instead of: > > > > > > <bb 2> [local count: 1073741824]: > > > if (A_2(D) == 0.0) > > > goto <bb 4>; [34.00%] > > > else > > > goto <bb 3>; [66.00%] > > > > > > <bb 3> [local count: 708669601]: > > > _3 = -A_2(D); > > > > > > <bb 4> [local count: 1073741824]: > > > # _1 = PHI <A_2(D)(2), _3(3)> > > > > > > It now sees: > > > > > > <bb 4> [local count: 1073741824]: > > > # _1 = PHI <0.0(2), _3(3)> > > > > > > which it leaves untouched, causing the if conditional to survive. > > > > > > Adding a variant to the pattern that for real_zerop fixes the problem. > > > > > > I am a match.pd weenie, and am avoiding touching more patterns that > > > may also benefit from handling real constants. So please use simple > > > words if what I'm doing isn't correct ;-). > > > > > > I did not include a testcase, as it's just phi-opt-24.c which will get > > > triggered when I commit the frange with endpoints work. > > > > > > Tested on x86-64 & ppc64le Linux. > > > > > > OK? > > > > > > gcc/ChangeLog: > > > > > > * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant > > > for real zero. > > > --- > > > gcc/match.pd | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/gcc/match.pd b/gcc/match.pd > > > index 1bb936fc401..5bdea300f94 100644 > > > --- a/gcc/match.pd > > > +++ b/gcc/match.pd > > > @@ -4803,6 +4803,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > > (cnd (cmp @0 zerop) @0 (negate@1 @0)) > > > (if (!HONOR_SIGNED_ZEROS (type)) > > > @1)) > > > + (simplify > > > + (cnd (cmp @0 zerop) real_zerop (negate@1 @0)) > > > + (if (!HONOR_SIGNED_ZEROS (type)) > > > + @1)) > > > (simplify > > > (cnd (cmp @0 zerop) integer_zerop (negate@1 @0)) > > > (if (!HONOR_SIGNED_ZEROS (type)) > > > > Looking at zerop: > > > > bool > > zerop (const_tree expr) > > { > > return (integer_zerop (expr) > > || real_zerop (expr) > > || fixed_zerop (expr)); > > } > > > > your patch is equivalent to changing the integer_zerop one to use zerop? > > (well, with the exception of also covering fixed_zerop). > > Heh. That was my first instinct, but I thought fixed_zerop didn't > apply? No clue...I'm happy to change it. Well, it already applies when the constant is not propagated, so ... > Thanks. > Aldy > > > > > OK if doing it that way. > > > > Thanks, > > Richard. > > > > > -- > > > 2.37.1 > > > > > >
On 8/29/2022 2:44 PM, Aldy Hernandez via Gcc-patches wrote: > The upcoming work for frange triggers a regression in > gcc.dg/tree-ssa/phi-opt-24.c. > > For -O2 -fno-signed-zeros, we fail to transform the following into -A: > > float f0(float A) > { > // A == 0? A : -A same as -A > if (A == 0) return A; > return -A; > } > > This is because the abs/negative match.pd pattern here: > > /* abs/negative simplifications moved from fold_cond_expr_with_comparison, > Need to handle (A - B) case as fold_cond_expr_with_comparison does. > Need to handle UN* comparisons. > ... > ... > > Sees IL that has the 0.0 propagated. > > Instead of: > > <bb 2> [local count: 1073741824]: > if (A_2(D) == 0.0) > goto <bb 4>; [34.00%] > else > goto <bb 3>; [66.00%] > > <bb 3> [local count: 708669601]: > _3 = -A_2(D); > > <bb 4> [local count: 1073741824]: > # _1 = PHI <A_2(D)(2), _3(3)> > > It now sees: > > <bb 4> [local count: 1073741824]: > # _1 = PHI <0.0(2), _3(3)> > > which it leaves untouched, causing the if conditional to survive. > > Adding a variant to the pattern that for real_zerop fixes the problem. > > I am a match.pd weenie, and am avoiding touching more patterns that > may also benefit from handling real constants. So please use simple > words if what I'm doing isn't correct ;-). > > I did not include a testcase, as it's just phi-opt-24.c which will get > triggered when I commit the frange with endpoints work. > > Tested on x86-64 & ppc64le Linux. > > OK? > > gcc/ChangeLog: > > * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant > for real zero. OK jeff
diff --git a/gcc/match.pd b/gcc/match.pd index 1bb936fc401..5bdea300f94 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -4803,6 +4803,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (cnd (cmp @0 zerop) @0 (negate@1 @0)) (if (!HONOR_SIGNED_ZEROS (type)) @1)) + (simplify + (cnd (cmp @0 zerop) real_zerop (negate@1 @0)) + (if (!HONOR_SIGNED_ZEROS (type)) + @1)) (simplify (cnd (cmp @0 zerop) integer_zerop (negate@1 @0)) (if (!HONOR_SIGNED_ZEROS (type))