From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94030 invoked by alias); 29 Jun 2017 09:53: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 92745 invoked by uid 89); 29 Jun 2017 09:53:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f178.google.com Received: from mail-wr0-f178.google.com (HELO mail-wr0-f178.google.com) (209.85.128.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Jun 2017 09:53:44 +0000 Received: by mail-wr0-f178.google.com with SMTP id r103so186809169wrb.0 for ; Thu, 29 Jun 2017 02:53:43 -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=zJJkiJmf1ICWwVe8skpnWQ2yA+fok2i/PCCi2YQD9Q4=; b=nSPUSlRNdrv9QgFTbIukKlDKMOT7t8O+tB4eQM2F1M3YBSm52f3xc28/vGlLik6AIR j4ajxI57UGqFbQRte6mnqpOcUraOGbA2ysDChV4QrGzupQIU0WA0NwR65BRPn1rDTGLD WSTZ8JA7QNI+UM/1Gtf9EtUpyVCvKpinexFibTd0Ehb2fmFApjzErid0PRG3Y1Sd51uM WQzso3rSvpfCi7MTtJ2f3pdHa4L2XmLG5isVLppMEMcapPpfVr1woTt0CBFHlw1dUwJz M0FzzdcFXHhOYUnQWCk65AtQUo48RgK5gXlnYDwv3TFOW99wrCtbCAmn+H+vofOhNUJO VEYA== X-Gm-Message-State: AKS2vOzCTjdooa4ThT4+mlzOwyqsGeX+P/ynm+inepJmQ/rZFBfNYquK b1iz9Ix4gwW9T32g54u2AZTChKVp6mbq X-Received: by 10.223.165.10 with SMTP id i10mr23934286wrb.59.1498730022029; Thu, 29 Jun 2017 02:53:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.111.196 with HTTP; Thu, 29 Jun 2017 02:53:41 -0700 (PDT) In-Reply-To: <0c48f7c0-6fff-c8f3-5680-e4a0fc3203bf@redhat.com> References: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> <20170627103822.GS2123@tucnak> <0c48f7c0-6fff-c8f3-5680-e4a0fc3203bf@redhat.com> From: Richard Biener Date: Thu, 29 Jun 2017 09:53:00 -0000 Message-ID: Subject: Re: Avoid generating useless range info To: Aldy Hernandez Cc: Jakub Jelinek , Andrew MacLeod , gcc-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg02243.txt.bz2 On Wed, Jun 28, 2017 at 9:56 AM, Aldy Hernandez wrote: > > > On 06/27/2017 06:38 AM, Jakub Jelinek wrote: >> >> 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). > > > Good point. Fixed. > >> /* 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? > > > Here, if SSA_NAME_RANGE_INFO is previously non-NULL then we proceed as > always-- just set the nonzero bits to whatever was specified (without > clearning SSA_NAME_RANGE_INFO). A mask of -1 and an SSA_NAME_RANGE_INFO of > non-NULL can coexist just fine. > > How about this? Ok. Thanks, Richard. > Aldy