From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90272 invoked by alias); 16 Aug 2016 22:20:44 -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 90263 invoked by uid 89); 16 Aug 2016 22:20:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-pf0-f179.google.com Received: from mail-pf0-f179.google.com (HELO mail-pf0-f179.google.com) (209.85.192.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Aug 2016 22:20:33 +0000 Received: by mail-pf0-f179.google.com with SMTP id y134so31482780pfg.0 for ; Tue, 16 Aug 2016 15:20:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jl9HwkrtClncUtcwyMcAhwtRaOiWPih17F/Eyxyxmyg=; b=OxIdsuq7aOgtJUbFB0gm2U21bCuqVYYxrP+c1sU04qb0HXMGzlAhBiYAJg9jwc/MWO DWC/oUnFo/0xyW0Ro7xra/qm5Alrv+TCFymdLxjQNL9sP1WhwcH9bFJ1ahmmPwfV/Qw/ iJWVhSHw5MAcGtTcRVF28xHPGn4smVDCJYlFYEXQZeJxgXU/V0puSEAuMWyhv3g5MZui 5ZBz+6yrQnSaCKDAKxNCpCLuiq7J26U5fRKoYfPcK5eDpL9hvpZJ5k0y+mRZeONBi7Pg kE1epTOP+8zWywHs7JbORLggEIm1hSKBJekC/AJxfE1MoIkeB1adWCW70Tvd4qaMso9I K1CA== X-Gm-Message-State: AEkoousaTQzrDs40IXkR5XB7AXL9H7u3DMUwtL5koCf6CFUVR/aL+7qZe74P8A5xpEiAug2T X-Received: by 10.98.108.3 with SMTP id h3mr68186520pfc.162.1471386032228; Tue, 16 Aug 2016 15:20:32 -0700 (PDT) Received: from [10.1.1.3] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.gmail.com with ESMTPSA id l128sm41713584pfl.21.2016.08.16.15.20.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 15:20:31 -0700 (PDT) Subject: Re: [RFC][IPA-VRP] Re-factor tree-vrp to factor out common code To: Richard Biener 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> Cc: "gcc-patches@gcc.gnu.org" , Jan Hubicka , Martin Jambor From: kugan Message-ID: Date: Tue, 16 Aug 2016 22:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01223.txt.bz2 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). 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 *); 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. Thanks, Kugan