From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110668 invoked by alias); 27 Jun 2017 10:38:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 108707 invoked by uid 89); 27 Jun 2017 10:38:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=46AM, 46am, rare X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Jun 2017 10:38:28 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5897880481; Tue, 27 Jun 2017 10:38:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5897880481 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5897880481 Received: from tucnak.zalov.cz (ovpn-116-143.ams2.redhat.com [10.36.116.143]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DBEAE7FB61; Tue, 27 Jun 2017 10:38:26 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v5RAcO0i027298; Tue, 27 Jun 2017 12:38:24 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v5RAcMsa027297; Tue, 27 Jun 2017 12:38:22 +0200 Date: Tue, 27 Jun 2017 10:38:00 -0000 From: Jakub Jelinek To: Aldy Hernandez Cc: Richard Biener , Andrew MacLeod , gcc-patches Subject: Re: Avoid generating useless range info Message-ID: <20170627103822.GS2123@tucnak> Reply-To: Jakub Jelinek References: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01999.txt.bz2 On Tue, Jun 27, 2017 at 06:26:46AM -0400, Aldy Hernandez wrote: > How about this? @@ -360,6 +363,22 @@ set_range_info (tree name, enum value_range_type range_type, } } +/* Store range information RANGE_TYPE, MIN, and MAX to tree ssa_name + NAME while making sure we don't store useless range info. */ + +void +set_range_info (tree name, enum value_range_type range_type, + const wide_int_ref &min, const wide_int_ref &max) +{ + /* A range of the entire domain is really no range at all. */ + tree type = TREE_TYPE (name); + if (min == wi::min_value (TYPE_PRECISION (type), TYPE_SIGN (type)) + && max == wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type))) + return; + + set_range_info_raw (name, range_type, min, max); +} + Won't this misbehave if we have a narrower range on some SSA_NAME and call set_range_info to make it VARYING? In that case (i.e. SSA_NAME_RANGE_INFO (name) != NULL), we should either set_range_info_raw too (if nonzero_bits is not all ones) or clear SSA_NAME_RANGE_INFO (otherwise). /* Gets range information MIN, MAX and returns enum value_range_type corresponding to tree ssa_name NAME. enum value_range_type returned @@ -419,9 +438,13 @@ set_nonzero_bits (tree name, const wide_int_ref &mask) { gcc_assert (!POINTER_TYPE_P (TREE_TYPE (name))); if (SSA_NAME_RANGE_INFO (name) == NULL) - set_range_info (name, VR_RANGE, - TYPE_MIN_VALUE (TREE_TYPE (name)), - TYPE_MAX_VALUE (TREE_TYPE (name))); + { + if (mask == -1) + return; + set_range_info_raw (name, VR_RANGE, + TYPE_MIN_VALUE (TREE_TYPE (name)), + TYPE_MAX_VALUE (TREE_TYPE (name))); + } range_info_def *ri = SSA_NAME_RANGE_INFO (name); ri->set_nonzero_bits (mask); Similarly, if SSA_NAME_RANGE_INFO is previously non-NULL, but min/max are VARYING and the new mask is -1, shouldn't we free it rather than set it to the default? If we consider the cases rare enough to worry about, at least your above if (min == wi::min_value (TYPE_PRECISION (type), TYPE_SIGN (type)) && max == wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type))) should be gcc_assert (!POINTER_TYPE_P (TREE_TYPE (name))); if (SSA_NAME_RANGE_INFO (name) == NULL && min == wi::min_value (TYPE_PRECISION (type), TYPE_SIGN (type)) && max == wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type))) We'd then not misbehave, just might in some rare cases keep SSA_NAME_RANGE_INFO non-NULL even if it contains the default stuff. Jakub