From patchwork Tue Nov 29 09:43:25 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 27128 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp233848wrr; Tue, 29 Nov 2022 01:44:20 -0800 (PST) X-Google-Smtp-Source: AA0mqf4uH0AHbyxe+751CTBsMekpFI/A/g8FXqTb6cghX6kZO6drjcv9YXkc4xb4thUtH+TMzN46 X-Received: by 2002:a17:906:383:b0:7be:bf2f:f7f with SMTP id b3-20020a170906038300b007bebf2f0f7fmr10421066eja.270.1669715060204; Tue, 29 Nov 2022 01:44:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669715060; cv=none; d=google.com; s=arc-20160816; b=OQfrdS6yyMICCXidGG7v4e+dm6+l7w0zd0G2t7UFCFcftispHqe5KeAuh46YJ4sApW C0Lo9cZi0j8SLFvug3+oI6plLgDpPhUShgwxn6VFXvYbf2sQMtZb5krWxMMcY+E9b4lF a1kQO9MmguqoCz3GXzXgTvMVHMYFihnH4LudYlfU8na2PjrU5S8RIBYuxhkaPmTbPfmf Oa91W0HPtN35m2mQoU08Sl22/9pMoMZWWWnMBVq1HD9zgozCk5N3Ww0OsbRWLqPKvXlB osPD8D55z8LVkUZEqaVPxitJNn29FM9lLRsV2InvNRSWXW02MGtJxrWUYuEdIfoP23kb 9/hQ== 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 :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=Nsnu+sIORFPkBm4LAiUpreXe+bkDeBQOQL+uGL459vA=; b=uCXgACGf9PmIk6wz7Vx3yWnqf44kjWeB+HNaDuC90pC+XgYAzQYRMKYt6pad+OFFik 9uN+1qv+Wg1GFu6qiURGuR6dKfETKkgHfmIS4XWoJBKanSLKlgccyoveRvMxaxq1DTqz h5+Qg0qpZaDU3GKZ78SjoiBjwKgFOd7NUseMmJrqh7rTTavod5Bv4UCcqUuZDfG9VhvF wo3ukYsSEFKLCPOj5lf7sWWjoZgGOKWicQepFoMvxzPTKpjozLIk9Ivqeu7fL9w1gJ71 Dkm7lH5NO2OTO1+RbkgYp87zb/zpuU7uIi0sPSXEwCq5Wv+R9a28UkYb30vy/tivBps0 rzmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=hKHjx7R7; 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 qw8-20020a1709066a0800b007adc8c49d83si10960996ejc.477.2022.11.29.01.44.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 01:44:20 -0800 (PST) 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=hKHjx7R7; 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 EFCA23858431 for ; Tue, 29 Nov 2022 09:44:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFCA23858431 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669715059; bh=Nsnu+sIORFPkBm4LAiUpreXe+bkDeBQOQL+uGL459vA=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=hKHjx7R7tTp7RswUur7lcyGATrS/sBy3vWFOamtPa0g4tIxNmfdTQLBChDs++GXgk //1SEtWL2VvW5kLOpAwxuDwBPF0PfPaEO7LtXsoUOMeH1DAOD0WBwTrs29YHtjNA2D eW4b8JuP6CkQlSyVfIk2KRq+90xo9BNWYJZFSVi0= 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 8CCAB3858431 for ; Tue, 29 Nov 2022 09:43:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8CCAB3858431 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-386-LRM9KJ1TP6q5iKUuIVkZ3Q-1; Tue, 29 Nov 2022 04:43:31 -0500 X-MC-Unique: LRM9KJ1TP6q5iKUuIVkZ3Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B07D83811F22 for ; Tue, 29 Nov 2022 09:43:31 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.114]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6E64B2166B2D; Tue, 29 Nov 2022 09:43:31 +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 2AT9hQJV4162579 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 29 Nov 2022 10:43:27 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2AT9hPgm4162578; Tue, 29 Nov 2022 10:43:25 +0100 Date: Tue, 29 Nov 2022 10:43:25 +0100 To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] range-op-float: Fix up multiplication and division reverse operation [PR107879] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.9 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?1750823138495885789?= X-GMAIL-MSGID: =?utf-8?q?1750823138495885789?= Hi! While for the normal cases it seems to be correct to implement reverse multiplication (op1_range/op2_range) through division with float_binary_op_range_finish, reverse division (op1_range) through multiplication with float_binary_op_range_finish or (op2_range) through division with float_binary_op_range_finish, as e.g. following testcase shows for the corner cases it is incorrect. Say on the testcase we are doing reverse multiplication, we have [-0., 0.] range (no NAN) on lhs and VARYING on op1 (or op2). We implement that through division, because x from lhs = x * op2 is x = lhs / op2 For the division, [-0., 0.] / VARYING is computed (IMHO correctly) as [-0., 0.] +-NAN, because 0 / anything but 0 or NAN is still 0 and 0 / 0 is NAN and ditto 0 / NAN. And then we just float_binary_op_range_finish, which figures out that because lhs can't be NAN, neither operand can be NAN. So, the end range is [-0., 0.]. But that is not correct for the reverse multiplication. When the result is 0, if op2 can be zero, then x can be anything (VARYING), to be precise anything but INF (unless result can be NAN), because anything * 0 is 0 (or NAN for INF). While if op2 must be non-zero, then x must be 0. Of course the sign logic (signbit(x) = signbit(lhs) ^ signbit(op2)) still holds, so it actually isn't full VARYING if both lhs and op2 have known sign bits. And going through other corner cases one by one shows other differences between what we compute for the corresponding forward operation and what we should compute for the reverse operations. The following patch is slightly conservative and includes INF (in case of result including 0 and not NAN) in the ranges or 0 in the ranges (in case of result including INF and not NAN). The latter is what happens anyway because we flush denormals to 0, and the former just not to deal with all the corner cases. So, the end test is that for reverse multiplication and division op2_range the cases we need to adjust to VARYING or VARYING positive or VARYING negative are if lhs and op? ranges both contain 0, or both contain some infinity, while for division op1_range the corner case is if lhs range contains 0 and op2 range contains INF or vice versa. Otherwise I believe ranges from the corresponding operation are ok, or could be slightly more conservative (e.g. for reverse multiplication, if op? range is singleton INF and lhs range doesn't include any INF, then x's range should be UNDEFINED or known NAN (depending on if lhs can be NAN), while the division computes [-0., 0.] +-NAN; or similarly if op? range is only 0 and lhs range doesn't include 0, division would compute +INF +-NAN, or -INF +-NAN, or (for lack of multipart franges -INF +INF +-NAN just VARYING +-NAN), while again it is UNDEFINED or known NAN. Oh, and I found by code inspection wrong condition for the division's known NAN result, due to thinko it would trigger not just when both operands are known to be 0 or both are known to be INF, but when either both are known to be 0, or at least one is known to be INF. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-11-29 Jakub Jelinek PR tree-optimization/107879 * range-op-float.cc (foperator_mult::op1_range): If both lhs and op2 ranges contain zero or both ranges contain some infinity, set r range to zero_to_inf_range depending on signbit_known_p. (foperator_div::op2_range): Similarly for lhs and op1 ranges. (foperator_div::op1_range): If lhs range contains zero and op2 range contains some infinity or vice versa, set r range to zero_to_inf_range depending on signbit_known_p. (foperator_div::rv_fold): Fix up condition for returning known NAN. Jakub --- gcc/range-op-float.cc.jj 2022-11-18 09:00:44.371322999 +0100 +++ gcc/range-op-float.cc 2022-11-28 19:45:50.347869350 +0100 @@ -2143,8 +2143,30 @@ public: range_op_handler rdiv (RDIV_EXPR, type); if (!rdiv) return false; - return float_binary_op_range_finish (rdiv.fold_range (r, type, lhs, op2), - r, type, lhs); + bool ret = rdiv.fold_range (r, type, lhs, op2); + if (ret == false) + return false; + const REAL_VALUE_TYPE &lhs_lb = lhs.lower_bound (); + const REAL_VALUE_TYPE &lhs_ub = lhs.upper_bound (); + const REAL_VALUE_TYPE &op2_lb = op2.lower_bound (); + const REAL_VALUE_TYPE &op2_ub = op2.upper_bound (); + if ((contains_zero_p (lhs_lb, lhs_ub) && contains_zero_p (op2_lb, op2_ub)) + || ((real_isinf (&lhs_lb) || real_isinf (&lhs_ub)) + && (real_isinf (&op2_lb) || real_isinf (&op2_ub)))) + { + // If both lhs and op2 could be zeros or both could be infinities, + // we don't know anything about op1 except maybe for the sign + // and perhaps if it can be NAN or not. + REAL_VALUE_TYPE lb, ub; + int signbit_known = signbit_known_p (lhs_lb, lhs_ub, op2_lb, op2_ub); + zero_to_inf_range (lb, ub, signbit_known); + r.set (type, lb, ub); + } + // Otherwise, if op2 is a singleton INF and lhs doesn't include INF, + // or if lhs must be zero and op2 doesn't include zero, it would be + // UNDEFINED, while rdiv.fold_range computes a zero or singleton INF + // range. Those are supersets of UNDEFINED, so let's keep that way. + return float_binary_op_range_finish (ret, r, type, lhs); } virtual bool op2_range (frange &r, tree type, const frange &lhs, @@ -2271,9 +2293,27 @@ public: { if (lhs.undefined_p ()) return false; - return float_binary_op_range_finish (fop_mult.fold_range (r, type, lhs, - op2), - r, type, lhs); + bool ret = fop_mult.fold_range (r, type, lhs, op2); + if (!ret) + return ret; + const REAL_VALUE_TYPE &lhs_lb = lhs.lower_bound (); + const REAL_VALUE_TYPE &lhs_ub = lhs.upper_bound (); + const REAL_VALUE_TYPE &op2_lb = op2.lower_bound (); + const REAL_VALUE_TYPE &op2_ub = op2.upper_bound (); + if ((contains_zero_p (lhs_lb, lhs_ub) + && (real_isinf (&op2_lb) || real_isinf (&op2_ub))) + || ((contains_zero_p (op2_lb, op2_ub)) + && (real_isinf (&lhs_lb) || real_isinf (&lhs_ub)))) + { + // If both lhs could be zero and op2 infinity or vice versa, + // we don't know anything about op1 except maybe for the sign + // and perhaps if it can be NAN or not. + REAL_VALUE_TYPE lb, ub; + int signbit_known = signbit_known_p (lhs_lb, lhs_ub, op2_lb, op2_ub); + zero_to_inf_range (lb, ub, signbit_known); + r.set (type, lb, ub); + } + return float_binary_op_range_finish (ret, r, type, lhs); } virtual bool op2_range (frange &r, tree type, const frange &lhs, @@ -2282,8 +2322,26 @@ public: { if (lhs.undefined_p ()) return false; - return float_binary_op_range_finish (fold_range (r, type, op1, lhs), - r, type, lhs); + bool ret = fold_range (r, type, op1, lhs); + if (!ret) + return ret; + const REAL_VALUE_TYPE &lhs_lb = lhs.lower_bound (); + const REAL_VALUE_TYPE &lhs_ub = lhs.upper_bound (); + const REAL_VALUE_TYPE &op1_lb = op1.lower_bound (); + const REAL_VALUE_TYPE &op1_ub = op1.upper_bound (); + if ((contains_zero_p (lhs_lb, lhs_ub) && contains_zero_p (op1_lb, op1_ub)) + || ((real_isinf (&lhs_lb) || real_isinf (&lhs_ub)) + && (real_isinf (&op1_lb) || real_isinf (&op1_ub)))) + { + // If both lhs and op1 could be zeros or both could be infinities, + // we don't know anything about op2 except maybe for the sign + // and perhaps if it can be NAN or not. + REAL_VALUE_TYPE lb, ub; + int signbit_known = signbit_known_p (lhs_lb, lhs_ub, op1_lb, op1_ub); + zero_to_inf_range (lb, ub, signbit_known); + r.set (type, lb, ub); + } + return float_binary_op_range_finish (ret, r, type, lhs); } private: void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan, @@ -2296,7 +2354,7 @@ private: { // +-0.0 / +-0.0 or +-INF / +-INF is a known NAN. if ((zero_p (lh_lb, lh_ub) && zero_p (rh_lb, rh_ub)) - || (singleton_inf_p (lh_lb, lh_ub) || singleton_inf_p (rh_lb, rh_ub))) + || (singleton_inf_p (lh_lb, lh_ub) && singleton_inf_p (rh_lb, rh_ub))) { real_nan (&lb, "", 0, TYPE_MODE (type)); ub = lb; --- gcc/testsuite/gcc.c-torture/execute/pr107879.c.jj 2022-11-28 19:53:06.720570324 +0100 +++ gcc/testsuite/gcc.c-torture/execute/pr107879.c 2022-11-28 19:51:57.281572677 +0100 @@ -0,0 +1,25 @@ +/* PR tree-optimization/107879 */ + +__attribute__((noipa)) static double +foo (double *y) +{ + volatile int ph = 0; + volatile double vf = 1.0; + double factor = vf; + double x = - (double) ph * factor; + if (x == 0) + *y = 1.0; + else + *y = 1.0 / x; + double w = 2.0 * x / factor; + double omww = 1 - w; + return omww > 0.0 ? omww : 0.0; +} + +int +main () +{ + double y = 42.0; + if (foo (&y) != 1.0) + __builtin_abort (); +}