From patchwork Sat Nov 12 18:30:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 60488 Return-Path: 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 8A1F038418AB for ; Sat, 12 Nov 2022 18:31:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A1F038418AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668277891; bh=trcT6rCTztHUKRsYFOFMnSr4athVpzul7afSasZe9z4=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=Enxk2XUbbS0mhGcnlzHmcr7Od9rxGMyqmHkDrGqUGAtNF/P/LX1/+z0qVMKj6Lw6c OU7LZ78iA4QiVeeJV7cEP4i/xBHwYvrivU+8AO2s9mhEMNXPwSkFJ8o+E5DMRkZGgq FVzoQJt6SCmQ2sLK5T8Bnorg+Gpz73ys7ArmilkY= 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 0AE2A3858410 for ; Sat, 12 Nov 2022 18:31:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0AE2A3858410 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-312-khJHeojrPRKsDK-ZpqSR4g-1; Sat, 12 Nov 2022 13:30:56 -0500 X-MC-Unique: khJHeojrPRKsDK-ZpqSR4g-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 46C39185A78F; Sat, 12 Nov 2022 18:30:56 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.192.46]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D3C0CC15BA4; Sat, 12 Nov 2022 18:30:55 +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 2ACIUpFQ389828 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 12 Nov 2022 19:30:51 +0100 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 2ACIUpDR389827; Sat, 12 Nov 2022 19:30:51 +0100 To: Richard Biener Cc: GCC patches , Andrew MacLeod , richard.sandiford@arm.com, Aldy Hernandez Subject: [PATCH] [PR68097] Try to avoid recursing for floats in tree_*_nonnegative_warnv_p. Date: Sat, 12 Nov 2022 19:30:48 +0100 Message-Id: <20221112183048.389811-1-aldyh@redhat.com> 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 X-Spam-Status: No, score=-11.4 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_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: Aldy Hernandez via Gcc-patches From: Aldy Hernandez Reply-To: Aldy Hernandez Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" It irks me that a PR named "we should track ranges for floating-point hasn't been closed in this release. This is an attempt to do just that. As mentioned in the PR, even though we track ranges for floats, it has been suggested that avoiding recursing through SSA defs in gimple_assign_nonnegative_warnv_p is also a goal. We can do this with various ranger components without the need for a heavy handed approach (i.e. a full ranger). I have implemented two versions of known_float_sign_p() that answer the question whether we definitely know the sign for an operation or a tree expression. Both versions use get_global_range_query, which is a wrapper to query global ranges. This means, that no caching or propagation is done. In the case of an SSA, we just return the global range for it (think SSA_NAME_RANGE_INFO). In the case of a tree code with operands, we also use get_global_range_query to resolve the operands, and then call into range-ops, which is our lowest level component. There is no ranger or gori involved. All we're doing is resolving the operation with the ranges passed. This is enough to avoid recursing in the case where we definitely know the sign of a range. Otherwise, we still recurse. Note that instead of get_global_range_query(), we could use get_range_query() which uses a ranger (if active in a pass), or get_global_range_query if not. This would allow passes that have an active ranger (with enable_ranger) to use a full ranger. These passes are currently, VRP, loop unswitching, DOM, loop versioning, etc. If no ranger is active, get_range_query defaults to global ranges, so there's no additional penalty. Would this be acceptable, at least enough to close (or rename the PR ;-))? PR tree-optimization/68097 gcc/ChangeLog: * fold-const.cc (known_float_sign_p): New. (tree_unary_nonnegative_warnv_p): Call known_float_sign_p. (tree_binary_nonnegative_warnv_p): Same. (tree_single_nonnegative_warnv_p): Same. --- gcc/fold-const.cc | 51 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index b89cac91cae..bd74cfca996 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -14577,6 +14577,44 @@ tree_simple_nonnegative_warnv_p (enum tree_code code, tree type) return false; } +/* Return true if T is of type floating point and has a known sign. + If so, set the sign in SIGN. */ + +static bool +known_float_sign_p (bool &sign, tree t) +{ + if (!frange::supports_p (TREE_TYPE (t))) + return false; + + frange r; + return (get_global_range_query ()->range_of_expr (r, t) + && r.signbit_p (sign)); +} + +/* Return true if TYPE is a floating-point type and (CODE OP0 OP1) has + a known sign. If so, set the sign in SIGN. */ + +static bool +known_float_sign_p (bool &sign, enum tree_code code, tree type, tree op0, + tree op1 = NULL_TREE) +{ + if (!frange::supports_p (type)) + return false; + + range_op_handler handler (code, type); + if (handler) + { + frange res, r0, r1; + get_global_range_query ()->range_of_expr (r0, op0); + if (op1) + get_global_range_query ()->range_of_expr (r1, op1); + else + r1.set_varying (type); + return handler.fold_range (res, type, r0, r1) && res.signbit_p (sign); + } + return false; +} + /* Return true if (CODE OP0) is known to be non-negative. If the return value is based on the assumption that signed overflow is undefined, set *STRICT_OVERFLOW_P to true; otherwise, don't change @@ -14589,6 +14627,10 @@ tree_unary_nonnegative_warnv_p (enum tree_code code, tree type, tree op0, if (TYPE_UNSIGNED (type)) return true; + bool sign; + if (known_float_sign_p (sign, code, type, op0)) + return !sign; + switch (code) { case ABS_EXPR: @@ -14656,6 +14698,10 @@ tree_binary_nonnegative_warnv_p (enum tree_code code, tree type, tree op0, if (TYPE_UNSIGNED (type)) return true; + bool sign; + if (known_float_sign_p (sign, code, type, op0, op1)) + return !sign; + switch (code) { case POINTER_PLUS_EXPR: @@ -14778,6 +14824,8 @@ tree_binary_nonnegative_warnv_p (enum tree_code code, tree type, tree op0, bool tree_single_nonnegative_warnv_p (tree t, bool *strict_overflow_p, int depth) { + bool sign; + if (TYPE_UNSIGNED (TREE_TYPE (t))) return true; @@ -14796,6 +14844,9 @@ tree_single_nonnegative_warnv_p (tree t, bool *strict_overflow_p, int depth) return RECURSE (TREE_OPERAND (t, 1)) && RECURSE (TREE_OPERAND (t, 2)); case SSA_NAME: + if (known_float_sign_p (sign, t)) + return !sign; + /* Limit the depth of recursion to avoid quadratic behavior. This is expected to catch almost all occurrences in practice. If this code misses important cases that unbounded recursion