From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 889 invoked by alias); 22 Jul 2016 12:49:41 -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 866 invoked by uid 89); 22 Jul 2016 12:49:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 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-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 Jul 2016 12:49:30 +0000 Received: by mail-wm0-f42.google.com with SMTP id o80so65137804wme.1 for ; Fri, 22 Jul 2016 05:49:29 -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=HPTrUGOQmzSUpmZmwkRSrVuoTSP8MNznaxtWyTUtIu8=; b=R/pOtgANNOwMPw5UiIdRh9Cdz63EYCjfM8Dz22m49w7f+F32GAUQVPkGISeUNncI7B QEC1waqYSq2nMD+JfsVWnJ70jtq9MoRdslAgirol41IRVElLdoWd0Z7PXB1BmS7bO+68 epJfRs3Zf2/4hluW/F6bL6dAvsqblHRjTpG4FlLeC7Hewt0dWXvQlxC1zUHWWhLKdWg+ IEatTjHEJE3td+i1RgT/J5ztRCJK6ppmrCNXWWpfKRw9OQuFdv57cMqoQYMsSzF/bGgi F4kw56gwMNhqYx1Zf7K+4OR2VervsaW9WI3FjowPaGWuhkw1CeaBjcf11WdP6SNMP5IE hNbQ== X-Gm-Message-State: AEkooutAeNoV2ieAES0SblXkbQsYn53Q8tGezica3D6XPTPPt8uYGTL7HXzAdq1Ma4ZhMAo8EA8KnUxuqv250Q== X-Received: by 10.28.214.130 with SMTP id n124mr4776392wmg.37.1469191767132; Fri, 22 Jul 2016 05:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Fri, 22 Jul 2016 05:49:26 -0700 (PDT) In-Reply-To: <21d3ea50-a799-0b5b-4736-3beeca7860c4@linaro.org> References: <57886949.8010300@linaro.org> <57886A2A.4070703@linaro.org> <21d3ea50-a799-0b5b-4736-3beeca7860c4@linaro.org> From: Richard Biener Date: Fri, 22 Jul 2016 12:49: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-07/txt/msg01480.txt.bz2 On Fri, Jul 22, 2016 at 2:27 PM, kugan wrote: > Hi, > > Now that early vrp is moved as part of tree-vrp, there is only minimal > interface tree-vrp should expose for ipa-vrp. However, I have not found the > right place to place struct value_range (with GTY marker) and enum > value_range_type. > > enum value_range_type is needed in tree-ssanames.[h|c] and in all the places > where get|set_range_info is used. > > struct value_range is needed in ipa-prop.h, therefore all the places > ipa-prop.h is included. > > One option is to place it in tree-vrp.h and expose this to GTY > infrastructure. Then include it in all the places we need any of these > types. It is in lots of c files. > > I have now placed both in tree.h. Even though that compiles, I am not > convinced that is the right place. I'm convinced it is not ;) As we had value_range_type in tree-ssanames.h why not put value_range there? Or simply put value_range into tree-vrp.h and leave value_range_type where it is. You no longer export vrp_finalize so no need to change it. > I would appreciate comment/preferences in this regard. I am also attaching > the current version of this patch for review. I will update it based on the > comments. Richard. > Thanks, > Kugan > > >