From patchwork Fri Mar 31 07:57:54 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 77706 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp445536vqo; Fri, 31 Mar 2023 03:02:22 -0700 (PDT) X-Google-Smtp-Source: AKy350a71/SnT/5P27k9JTt4vs5/pHBvE2WtpIL3B4m9UAjLPYdGiIRKri4E8Adu3cU2WAVlCr4K X-Received: by 2002:a17:906:31cb:b0:92c:a80e:225f with SMTP id f11-20020a17090631cb00b0092ca80e225fmr29666557ejf.52.1680256942809; Fri, 31 Mar 2023 03:02:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680256942; cv=none; d=google.com; s=arc-20160816; b=sK32P3pWUYLx1FAZ/8Cgw/nAI+aWvEl8q2mSNjjV7EjJ1oPF+/MyAJDzIwBRQeg1sn EjZJDyCrfNhc6LmMrBYgHM1YENXo9NpbrbAEkgRiUxIi6waujABuHbG2Gy526lSe73/y 5zwcAo7f32zRRylddq6qQMKTWOlQqOJVv5Q2zw9RSwo5x/WvgNj1kjAxP4fqPBBHlz9y ukE+uesbG0nS3gQqz86vuca9JxZC2Cpf1aULNroQXJnO6fdKgcMdAfafvxt1Ith+zMqP Ui9v6fjODrAUyhSz4np04SSIwQ44ckEecIAg0elJzrIEf+fzcSo7UT7iy/fEGVEPIEeR asuQ== 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:message-id:subject:cc:to:date :resent-to:resent-message-id:resent-date:resent-from:dmarc-filter :delivered-to:dkim-signature:dkim-filter; bh=gAYi7wcT+r5eEu31vilGDzr8pbAKt8sMDTXa9++K+XY=; b=h1GpXA9EriPptjORW3KUGv+5xCWTK4gsst37EkErI6o8rrkueR4NJXFfMAvtgDXFFP YMhlykOSvAP+rWuSUQgE/WUd8mL3/OE0FEAbHtBcK2HV9XehEKmbHeo0UfiyjRW1OtrG 4hd71MeixGK4juNKP319U7QSQS/2DTWsjB8TkUsjtCATcQ5r25P2/l08WAeMzY8h1rfq VkuOv0a/txYWH2W5RB9O6b8axJtoxLSUjtTWmrWA7Z5nBhqqGK9nHNs2IAiDBFYLIEaA k5O7atWT6ct094/jO8b4SfejwW15WtZz6H9l1KKbgwYjLTmaxWYupErvA9Nebu0JsK6B 7NhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=K0fg9MmT; 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 lb23-20020a170906add700b009268b9aa263si1371741ejb.306.2023.03.31.03.02.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Mar 2023 03:02:22 -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=K0fg9MmT; 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 C092D3853D1E for ; Fri, 31 Mar 2023 10:02:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C092D3853D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680256928; bh=gAYi7wcT+r5eEu31vilGDzr8pbAKt8sMDTXa9++K+XY=; h=Resent-From:Resent-Date:Resent-To:Date:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=K0fg9MmTdMoEcKJ2dTIYb/53huuQMxOYH7BRplSFGrnWzsALnymceQ7lnKEceyrI8 zI+bG86X7VDAOG7IHJLtlk4S/pXNUUo1GIZDbAE3CS1RxKp0oCExUfsUYRKQHlC1eb 7m52Rg/en/DadhptQmBWmQNpVpRNTxSY5qH+OUhQ= 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.133.124]) by sourceware.org (Postfix) with ESMTPS id D61123858D33 for ; Fri, 31 Mar 2023 10:01:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D61123858D33 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-76-wtv0vu61Nqibi3qk8RI-Pw-1; Fri, 31 Mar 2023 06:01:17 -0400 X-MC-Unique: wtv0vu61Nqibi3qk8RI-Pw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F112728082B2 for ; Fri, 31 Mar 2023 10:01:16 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B3FD9C15BA0; Fri, 31 Mar 2023 10:01:16 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 32VA1ECX3973722 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 31 Mar 2023 12:01:14 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 32VA1Dsl3973721; Fri, 31 Mar 2023 12:01:13 +0200 Resent-From: Jakub Jelinek Resent-Date: Fri, 31 Mar 2023 12:01:13 +0200 Resent-Message-ID: Resent-To: Aldy Hernandez , Andrew MacLeod , gcc-patches@gcc.gnu.org Date: Fri, 31 Mar 2023 09:57:54 +0200 To: Aldy Hernandez , Andrew MacLeod Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] range-op-float, value-range: Fix up handling of UN{LT,LE,GT,GE,EQ}_EXPR and handle comparisons in get_tree_range [PR91645] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761877104056579256?= X-GMAIL-MSGID: =?utf-8?q?1761877104056579256?= Hi! When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR comparisons incorrectly. All those are unordered or ..., we correctly return [1, 1] if one or both operands are known NANs, and correctly ask the non-UN prefixed op to fold_range if neither operand may be NAN. But for the case where one or both operands may be NAN, we always return [0, 1]. The UN* fold_range tries to handle it by asking the non-UN prefixed fold_range and if it returns [1, 1] return that, if it returns [0, 0] or [0, 1] return [0, 1], which makes sense, because the maybe NAN means that it is the non-UN prefixed fold_range unioned with [1, 1] in case the maybe NAN is actually NAN at runtime. The problem is that the non-UN prefixed fold_range always returns [0, 1] because those fold_range implementations are like: if (op1.known_isnan () || op2.known_isnan ()) r = range_false (type); else if (!maybe_isnan (op1, op2)) { ... } else r = range_true_and_false (type); and so if maybe_isnan, they always return [0, 1]. Now, thinking about it, this is unnecessary pessimization, for the case where the ... block returns range_false (type) we actually could do it also if maybe_isnan (op1, op2), because if one or both operands are NAN, the comparison will be false, and if neither is NAN, the comparison will be also false. Will fix incrementally today. Anyway, the following patch fixes it by asking the non-UN prefixed fold_range on ranges with NAN cleared, which I think does the right thing in all cases. Another change in the patch is that range_query::get_tree_range always returned VARYING for comparisons, this patch allows to ask about those as well (they are very much like binary ops, except they take the important type from the types of the operands rather than result). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-03-31 Jakub Jelinek PR tree-optimization/91645 * range-op-float.cc (foperator_unordered_lt::fold_range, foperator_unordered_le::fold_range, foperator_unordered_gt::fold_range, foperator_unordered_ge::fold_range, foperator_unordered_equal::fold_range): Call the ordered fold_range on ranges with cleared NaNs. * value-query.cc (range_query::get_tree_range): Handle also COMPARISON_CLASS_P trees. Jakub --- gcc/range-op-float.cc.jj 2023-03-28 11:00:29.205986288 +0200 +++ gcc/range-op-float.cc 2023-03-30 15:14:12.219183066 +0200 @@ -1587,7 +1587,13 @@ public: r = range_true (type); return true; } - if (!fop_lt.fold_range (r, type, op1, op2, rel)) + frange op1_no_nan = op1; + frange op2_no_nan = op2; + if (op1.maybe_isnan ()) + op1_no_nan.clear_nan (); + if (op2.maybe_isnan ()) + op2_no_nan.clear_nan (); + if (!fop_lt.fold_range (r, type, op1_no_nan, op2_no_nan, rel)) return false; // The result is the same as the ordered version when the // comparison is true or when the operands cannot be NANs. @@ -1692,7 +1698,13 @@ public: r = range_true (type); return true; } - if (!fop_le.fold_range (r, type, op1, op2, rel)) + frange op1_no_nan = op1; + frange op2_no_nan = op2; + if (op1.maybe_isnan ()) + op1_no_nan.clear_nan (); + if (op2.maybe_isnan ()) + op2_no_nan.clear_nan (); + if (!fop_le.fold_range (r, type, op1_no_nan, op2_no_nan, rel)) return false; // The result is the same as the ordered version when the // comparison is true or when the operands cannot be NANs. @@ -1793,7 +1805,13 @@ public: r = range_true (type); return true; } - if (!fop_gt.fold_range (r, type, op1, op2, rel)) + frange op1_no_nan = op1; + frange op2_no_nan = op2; + if (op1.maybe_isnan ()) + op1_no_nan.clear_nan (); + if (op2.maybe_isnan ()) + op2_no_nan.clear_nan (); + if (!fop_gt.fold_range (r, type, op1_no_nan, op2_no_nan, rel)) return false; // The result is the same as the ordered version when the // comparison is true or when the operands cannot be NANs. @@ -1898,7 +1916,13 @@ public: r = range_true (type); return true; } - if (!fop_ge.fold_range (r, type, op1, op2, rel)) + frange op1_no_nan = op1; + frange op2_no_nan = op2; + if (op1.maybe_isnan ()) + op1_no_nan.clear_nan (); + if (op2.maybe_isnan ()) + op2_no_nan.clear_nan (); + if (!fop_ge.fold_range (r, type, op1_no_nan, op2_no_nan, rel)) return false; // The result is the same as the ordered version when the // comparison is true or when the operands cannot be NANs. @@ -2002,7 +2026,13 @@ public: r = range_true (type); return true; } - if (!fop_equal.fold_range (r, type, op1, op2, rel)) + frange op1_no_nan = op1; + frange op2_no_nan = op2; + if (op1.maybe_isnan ()) + op1_no_nan.clear_nan (); + if (op2.maybe_isnan ()) + op2_no_nan.clear_nan (); + if (!fop_equal.fold_range (r, type, op1_no_nan, op2_no_nan, rel)) return false; // The result is the same as the ordered version when the // comparison is true or when the operands cannot be NANs. --- gcc/value-query.cc.jj 2023-03-23 15:25:47.069740988 +0100 +++ gcc/value-query.cc 2023-03-30 15:20:58.733237311 +0200 @@ -230,15 +230,21 @@ range_query::get_tree_range (vrange &r, default: break; } - if (BINARY_CLASS_P (expr)) + if (BINARY_CLASS_P (expr) || COMPARISON_CLASS_P (expr)) { - range_op_handler op (TREE_CODE (expr), type); + tree op0 = TREE_OPERAND (expr, 0); + tree op1 = TREE_OPERAND (expr, 1); + if (COMPARISON_CLASS_P (expr) + && !Value_Range::supports_type_p (TREE_TYPE (op0))) + return false; + range_op_handler op (TREE_CODE (expr), + BINARY_CLASS_P (expr) ? type : TREE_TYPE (op0)); if (op) { - Value_Range r0 (TREE_TYPE (TREE_OPERAND (expr, 0))); - Value_Range r1 (TREE_TYPE (TREE_OPERAND (expr, 1))); - range_of_expr (r0, TREE_OPERAND (expr, 0), stmt); - range_of_expr (r1, TREE_OPERAND (expr, 1), stmt); + Value_Range r0 (TREE_TYPE (op0)); + Value_Range r1 (TREE_TYPE (op1)); + range_of_expr (r0, op0, stmt); + range_of_expr (r1, op1, stmt); if (!op.fold_range (r, type, r0, r1)) r.set_varying (type); }