From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53404 invoked by alias); 19 Jul 2016 20:14:13 -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 53387 invoked by uid 89); 19 Jul 2016 20:14:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=management X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 19 Jul 2016 20:14:05 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4B9B131A327; Tue, 19 Jul 2016 20:14:04 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6JKE39S030629; Tue, 19 Jul 2016 16:14:03 -0400 Subject: Re: [RFC][IPA-VRP] Early VRP Implementation To: Richard Biener , Andrew Pinski , kugan References: <57886949.8010300@linaro.org> <57886A71.6030103@linaro.org> <51e838ff-da7e-bae8-c905-4e6d4b3c8a73@redhat.com> <3A0A8D76-351F-4ACA-8309-8FEE6B57979E@gmail.com> Cc: "gcc-patches@gcc.gnu.org" , Jan Hubicka , Martin Jambor From: Jeff Law Message-ID: Date: Tue, 19 Jul 2016 20:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <3A0A8D76-351F-4ACA-8309-8FEE6B57979E@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg01184.txt.bz2 On 07/19/2016 12:35 PM, Richard Biener wrote: >> I wouldn't mind seeing tree-vrp broken down a little -- it's quite >> large and there's at least 4 distinct things going on in that >> file. >> >> 1. ASSERT_EXPR handling. >> >> 2. Arithmetic on ranges >> >> 3. Propagation engine setup, callbacks, etc >> >> 4. Range management >> >> There may be others, but it seems at least some of that ought to be >> factored out. > > Possibly, but not necessarily because of the proposed pass. Right. These are things that, in my mind ought to be done regardless of the introduction of IPA-VRP. > > I'd like to see lattices and lattice entries becoming classes and the > arithmetic on it being templated on it. Seems reasonable as well. > > I do have some preliminary patches implementing a aggressive > on-drmand VRP for the use in niter analysis and the Lattice is what > makes sharing code difficult (it's a hash-map instead of an array > there). It's interesting you mention an on-demand VRP. I've asked Andrew to poke that that some too. It's for a different need, but interesting that we're both looking to take things in that direction. Jeff