From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76062 invoked by alias); 17 Aug 2016 13:46:16 -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 76052 invoked by uid 89); 17 Aug 2016 13:46:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Aug 2016 13:46:05 +0000 Received: by mail-wm0-f48.google.com with SMTP id i5so233442973wmg.0 for ; Wed, 17 Aug 2016 06:46:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d/qolVygxSiUA0k5miW2tGWJIYswxb0TI0D/nrljmA4=; b=bgiOXpo4bBPKNd45oBjbhdXAg3FXvGNyryacYqtX8ULLLYCP33/VatkDMLo3qUfNmK Porz1+6XSg7DfNe/OrpsXi9sO3Ds/VIYciMmPtLQ+9j0unHEIGlBwucyf8ftvO63gtg1 xenJLszoQTdYK6jgCLVTzCDMIO/IAR+wnydes4cQZ5cfqEJohXlCOapubVoqNSvcAeKn XxGkEXwU1La/a4HHo+aEkNp1/uTWnTszsZqUJEfWk30mF62oYu1HoNOI39n5VyWdb0ov ctXPRbMHOx22VoGXq6fTL41ld/lpij0hFFjt3gND2qSrqsjo2DtyM9AHCbsO5ZOFoZky fZfw== X-Gm-Message-State: AEkoouvyT4jjzaGRnfsT2XgefKFyFpAf3q6EUkQ7SteXAAmDQ1F993Y76BD31Il0IGrBP00gwILX5glozhQsOw== X-Received: by 10.194.107.33 with SMTP id gz1mr48260622wjb.178.1471441562956; Wed, 17 Aug 2016 06:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Wed, 17 Aug 2016 06:46:02 -0700 (PDT) In-Reply-To: References: <57886949.8010300@linaro.org> <57886A2A.4070703@linaro.org> <21d3ea50-a799-0b5b-4736-3beeca7860c4@linaro.org> <89a0bb8c-2744-49c5-8c4b-e2b4e92a26c3@linaro.org> <64f0e8a8-a933-53ff-bc60-e21db86f2608@linaro.org> <83dbcfbd-8e81-7df9-3519-5f98a332dfd2@linaro.org> From: Richard Biener Date: Wed, 17 Aug 2016 13:46:00 -0000 Message-ID: Subject: Re: [RFC][IPA-VRP] Re-factor tree-vrp to factor out common code To: kugan Cc: "gcc-patches@gcc.gnu.org" , Jan Hubicka , Martin Jambor Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01268.txt.bz2 On Wed, Aug 17, 2016 at 4:50 AM, kugan wrote: > Hi Richard, > > > On 17/08/16 08:20, kugan wrote: >> >> Hi, >> >> On 16/08/16 21:56, Richard Biener wrote: >>> >>> On Tue, Aug 16, 2016 at 10:09 AM, kugan >>> wrote: >>>> >>>> >>>> >>>> >>>> On 23/07/16 20:12, kugan wrote: >>>>> >>>>> >>>>> Hi Richard, >>>>> >>>>>>> As we had value_range_type in tree-ssanames.h why not put value_range >>>>>>> there? >>>>>>> >>>>>> For IPA_VRP, we now need value_range used in ipa-prop.h (in ipa-vrp >>>>>> patch). Based on this, attached patch now adds struct value_range to >>>>>> tree-ssanames.h and fixes the header files. Please note that I also >>>>>> had >>>>>> to add other headers in few places due to the dependency. Are you OK >>>>>> with this ? >>>>> >>>>> >>>>> Here is alternate patch where we keep struct value_range and enum >>>>> value_range_type to tree-vrp.h. May be it is a better approach? Please >>>>> let me know what is your preference. >>>>> >>>> >>>> Ping? >>>> >>>> This patch places value_range_type and value_range in tree-vrp.h. May be >>>> this is better? >>>> >>>> Alternate patch which keeps value_range_type and value_range in >>>> tree-ssanames.h is in: >>>> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01491.html >>>> >>>> I also added the necessary header files changed needed for ipa-vrp as >>>> part >>>> of this patch so that changes needed are clear. >>> >>> >>> I think tree-vrp.h is a better place. Please don't export functions >>> you don't need >>> (the _1 helpers). > > I had unintentionally removed a static from a _1 helper. I think thats what > caused the confusion. I also added constant modifiers to parameters mainly > due to ipa-vrp passing second parameters to lattice operation as const. > >> Agreed. >> >> I have exported the following for now: >> +extern void vrp_intersect_ranges (value_range *vr0, value_range *vr1); >> +extern void vrp_meet (value_range *vr0, const value_range *vr1); >> +extern void dump_value_range (FILE *, const value_range *); > > > This again is the exported operations. > >> It might be useful to add vrp_unary_op, vrp_binary_op on value_range. >> But that is for later if that is needed. >> >>> >>> I still believe sharing vrp_initialize/finalize is wrong and the >>> lattice setup / teardown >>> should be split out. >> >> >> I have done that too as part of the early-vrp patch in: >> >> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01155.html >> >> I just wanted to focus on the functionality required for the IPA-VRP on >> this patch. > > > > Attaching the latest version of the patch. Is this OK? Yes. Thanks, Richard. > Thanks, > Kugan