From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-19.smtpout.orange.fr [80.12.242.19]) by sourceware.org (Postfix) with ESMTPS id 677323858C27 for ; Thu, 26 Oct 2023 16:41:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 677323858C27 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 677323858C27 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.12.242.19 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698338519; cv=none; b=cokLHzxSIsbj27kKMAzAMhg+rB3bSvPYGvtWuVsSFE7IS+d99SKALTdZmE+g8PwLQce8Mp29US3n6uTzTvvn/idWVpbtrnpFkHJGQQDjSnyg0TsV6YtkxbK41yr/imEeAP4o+QkAXyFenQ/7wyIRdV/w0nhSM8sm8rJ0S79p3U0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698338519; c=relaxed/simple; bh=mZg5/OOm5QhMt4ECfYT8UWXpLWDdYu2XNoqEwFNqskk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=kOPGJveegG8inVtaDFwf+1qhP2DviOwtcgWmtsyeZgc/bIDOcYFszXusuB6BgB3o3WwbBZY9FT4x8JFip38l0LNsPs/HT9TiYf47j5i1SiqCMf8gMv69JlU47YRYPBHX+P551FwpTJsfGHAiVFdvcLzt9Hs7d+iEJ2vk3wewlE8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.1.16] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id w3QcqYPpUvx99w3Qiqt4qt; Thu, 26 Oct 2023 18:41:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1698338517; bh=4IKugYmM4DpGqZeu5mJ2sCWXU8AJLJR5HR5jbODk4NA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Tw2XbNTrEuEiZiq6jmSDY71fVvcxb2EVbLp7v9HEGdFuSdGeIIOjxD0jL85/YqlXt QGyFHXDJftuonygZF4WRYKVetWOseFIYVZZJUdTM9iuVP5PveLTLMbU4h54Q6WnNY1 BmWyQQg3T7p/bo2f9OPmq/cZFbiq/vWflSv/lt9FSQfaorOaxAoyl3Iqefq1qbKNJR nzfauuWGf2pwJfmJFkE4sjI5NhZht3u/f+cVqLsST/Ue/vRTujQycWANvrpOPpJ9JW XbwczP5GNzofzR+MOYm33hOE4B9EmUPbqj1SHWJTi4LR3i50ICa6hHaYFW0KQ6tluS 18yh111xdewJw== X-ME-Helo: [192.168.1.16] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Thu, 26 Oct 2023 18:41:57 +0200 X-ME-IP: 86.215.161.51 Message-ID: Date: Thu, 26 Oct 2023 18:41:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Improve tree_expr_nonnegative_p by using the ranger [PR111959] To: Richard Biener , Andrew Pinski Cc: gcc-patches@gcc.gnu.org References: <20231025035046.3918756-1-pinskia@gmail.com> Content-Language: en-US From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 List-Id: Le 26/10/2023 à 11:29, Richard Biener a écrit : > On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote: >> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc >> index 40767736389..2a2a90230f5 100644 >> --- a/gcc/fold-const.cc >> +++ b/gcc/fold-const.cc >> @@ -15047,15 +15047,33 @@ 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: >> - /* 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 >> - would not, passes that need this information could be revised >> - to provide it through dataflow propagation. */ >> - return (!name_registered_for_update_p (t) >> - && depth < param_max_ssa_name_query_depth >> - && gimple_stmt_nonnegative_warnv_p (SSA_NAME_DEF_STMT (t), >> - strict_overflow_p, depth)); >> + { >> + /* For integral types, querry the global range if possible. */ > > query > >> + if (INTEGRAL_TYPE_P (TREE_TYPE (t))) >> + { >> + value_range vr; >> + if (get_global_range_query ()->range_of_expr (vr, t) >> + && !vr.varying_p () && !vr.undefined_p ()) >> + { >> + /* If the range is nonnegative, return true. */ >> + if (vr.nonnegative_p ()) >> + return true; >> + >> + /* If the range is non-positive, then return false. */ >> + if (vr.nonpositive_p ()) >> + return false; > > That's testing for <= 0, nonnegative for >= 0. This means when > vr.nonpositive_p () the value could still be zero (and nonnegative), > possibly be figured out by the recursion below. > > Since we don't have negative_p () do we want to test > nonpositive_p () && nonzero_p () instead? > Maybe !contains_zero_p () instead of nonzero_p () ? nonzero_p seems to check that the range is exactly the "all but zero" range as visible in the implementation: inline bool irange::nonzero_p () const { if (undefined_p ()) return false; wide_int zero = wi::zero (TYPE_PRECISION (type ())); return *this == int_range<2> (type (), zero, zero, VR_ANTI_RANGE); }