From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12179 invoked by alias); 23 Jun 2017 10:24:46 -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 3911 invoked by uid 89); 23 Jun 2017 10:24:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1759 X-HELO: mail-ot0-f177.google.com Received: from mail-ot0-f177.google.com (HELO mail-ot0-f177.google.com) (74.125.82.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jun 2017 10:24:37 +0000 Received: by mail-ot0-f177.google.com with SMTP id 95so28610223ott.3 for ; Fri, 23 Jun 2017 03:24:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=upJP9F0HybhyHupv4jmxB+PN73mJJWMsMfpKevlfewE=; b=Iee7wvCgoL5M0lDLlNEoAqfiSaMfYl58+sPoJ/U3NqP69gSYkkiFLPYhKY7T/77qG8 zw0HI1+nTI4ZyiWlWOB/w/t6q7EB6BQiv/NgiyxJwaRMIlGorAKpFg1FhMsdaezCBwS7 bgCkEYyax9OJlWnhwP8YiEibKh4a2XBxg31IKU/LuEhK6L+Yo4W7GjvYZPSfiYbsGNgw hsaYcRbeHxtxO0HxoTKe+jf6F3t7DIpiqTtBJez1lum3EH1Lfh72nKgBUSS4wXWddPwr aGyXg7hOS2cKOqlf4anw5w3iMZQP49YNpQ9yqqxlNgyGfu+hScdeCWkUn06PURDmMQE4 cU/w== X-Gm-Message-State: AKS2vOwWlZb+7OB2czP7P7NjIV3y4R76iCPmZxDqcXMfnUpBSZKNnpDz D8jcfR9YcDZ3ZG/4NsPpEkU2FmBXow== X-Received: by 10.157.38.164 with SMTP id l33mr4412634otb.197.1498213465913; Fri, 23 Jun 2017 03:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.66 with HTTP; Fri, 23 Jun 2017 03:24:25 -0700 (PDT) In-Reply-To: References: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> From: Richard Biener Date: Fri, 23 Jun 2017 10:24:00 -0000 Message-ID: Subject: Re: Avoid generating useless range info To: Aldy Hernandez Cc: Andrew MacLeod , gcc-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01755.txt.bz2 On Fri, Jun 23, 2017 at 10:59 AM, Aldy Hernandez wrote: > > > On Fri, Jun 16, 2017 at 4:00 AM, Richard Biener > wrote: >> >> On Wed, Jun 14, 2017 at 6:41 PM, Aldy Hernandez wrote: >> > Hi! >> > >> > As discovered in my range class work, we seem to generate a significant >> > amount of useless range info out of VRP. >> > >> > Is there any reason why we can't avoid generating any range info that >> > spans >> > the entire domain, and yet contains nothing in the non-zero bitmask? >> > >> > The attached patch passes bootstrap, and the one regression it causes is >> > because now the -Walloca-larger-than= pass is better able to determine >> > that >> > there is no range information at all, and the testcase is unbounded. >> > So...win, win. >> > >> > OK for trunk? >> >> Can you please do this in set_range_info itself? Thus, if min == >> wi::min_value && max == wi::max_value >> simply return? (do not use TYPE_MIN?MAX_VALUE please) > > > The reason I did it in vrp_finalize is because if you do it in > set_range_info, you break set_nonzero_bits when setting bits on an SSA that > currently has no range info: > > void > 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))); > range_info_def *ri = SSA_NAME_RANGE_INFO (name); > ri->set_nonzero_bits (mask); > } > > Let me know how you'd like me to proceed. Just factor out a set_range_info_raw and call that then from here. Richard. > Aldy > >> >> Thanks, >> Richard. >> >> > Aldy > >