From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117475 invoked by alias); 16 Jun 2017 08:00:29 -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 116858 invoked by uid 89); 16 Jun 2017 08:00:05 -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:836 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, 16 Jun 2017 08:00:01 +0000 Received: by mail-ot0-f177.google.com with SMTP id u13so10941338otd.2 for ; Fri, 16 Jun 2017 01:00:06 -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=nU7wsmR1j3Ij+YGzgwKpRsL8a/0IIBUcZJSrxFiyMcE=; b=IUjlicpc8FUGuiw1Sbxv/MD9kXDTodQqoz388jFwlKhC8VqMdQmDfvZ5P1yJzsjtLq isNWmr+wmh8bEvRiemwxzYmrKoCqx/n2UHo8yjEEB6UYdvHhvSEOFK3GFqqXRKqMQvX5 eUmjGmo4kI0Br+CO3U1LLqMJreU0pGOfgEDABp/Bel/BlA+yBPDqLfp3h9vwCzUAWVhY miKhq7mjO0ZWChh5M3PHPJV2Zy4anpdAUBY9VepMipoDte69lditL/SBii6WIFDfm3Dh RbeZL7nFlxh8Q+Z3r2ZWSQzZ081k8T8L2GX4BeBdjAxTfeevKEuMifUdmn0T86LNLlwt 68Kw== X-Gm-Message-State: AKS2vOzJ1rqiiluxCs9NfbzFlKnu0kKx1HCz+2C4p6KXZ4wUzDN/YnV9 gS1zMx+sVGhG46jGIPDssfO5or1uXA== X-Received: by 10.157.49.3 with SMTP id e3mr6014479otc.254.1497600005015; Fri, 16 Jun 2017 01:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.66 with HTTP; Fri, 16 Jun 2017 01:00:04 -0700 (PDT) In-Reply-To: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> References: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> From: Richard Biener Date: Fri, 16 Jun 2017 08:00: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/msg01167.txt.bz2 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) Thanks, Richard. > Aldy