From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99974 invoked by alias); 23 Jun 2017 09:02:52 -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 99229 invoked by uid 89); 23 Jun 2017 09:02:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-ot0-f182.google.com Received: from mail-ot0-f182.google.com (HELO mail-ot0-f182.google.com) (74.125.82.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jun 2017 09:02:47 +0000 Received: by mail-ot0-f182.google.com with SMTP id u13so27530550otd.2 for ; Fri, 23 Jun 2017 02:02:46 -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=U8GyuAWzOMK19oSgxw/MqJmOOQ2hpn4bHEbi8jh0pM0=; b=dqYHrgAp/yRrv/kEp2XtF4OFno03Qrg3hmv3ivx9IU59Z3BKQiNXDFVYXH+FV2bJni UYnqp3NJPQyxghQ8X4SX51ZBh2dNkfDVjkDQ0/2fF8P7JBlK1aaaGcx3tGcERWHQi+/T KG8Mpr8JWdjBhuP+SUzh9AHQz9sz51Ro/Jycc1FrD/BUUECIMdToSy1l8PUCpHZG8kqH fqR04reISuhWd8kISNJi5oYh7PIGWsc+H6kTLktgIkax7yQ/2j90So22F1vB/bJgTMI3 KjsnhRAO1g44rdtxd9cTfUccbGF8NhQ0RTNBPuJ4fNcZzEJz2AwZ8HF5cAjZ1s4DY6PA nUJw== X-Gm-Message-State: AKS2vOyLIBJglcqVjQ8ShW4dYxB9JNgeSYZF/6ejg3Y7kZSa10D8I/Ua /6Ux9Hp5ynZpHokTElT6x/zbtk01BkKZ X-Received: by 10.157.22.136 with SMTP id c8mr3137834ote.45.1498208565517; Fri, 23 Jun 2017 02:02:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.12.156 with HTTP; Fri, 23 Jun 2017 02:02:45 -0700 (PDT) In-Reply-To: References: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> From: Aldy Hernandez Date: Fri, 23 Jun 2017 09:02:00 -0000 Message-ID: Subject: Re: Avoid generating useless range info To: Richard Biener Cc: Andrew MacLeod , gcc-patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-06/txt/msg01744.txt.bz2 [one more time, but without sending html which the list refuses :-/] 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. Aldy > > Thanks, > Richard. > >> Aldy