From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92901 invoked by alias); 24 Oct 2017 20:49:37 -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 92892 invoked by uid 89); 24 Oct 2017 20:49:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=forgot 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 ESMTP; Tue, 24 Oct 2017 20:49:35 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 370686A7D8 for ; Tue, 24 Oct 2017 20:49:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 370686A7D8 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dmalcolm@redhat.com Received: from ovpn-116-224.phx2.redhat.com (ovpn-116-224.phx2.redhat.com [10.3.116.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id C1AA65D6A2; Tue, 24 Oct 2017 20:49:33 +0000 (UTC) Message-ID: <1508878173.17132.26.camel@redhat.com> Subject: Re: [RFA][PATCH] Provide a class interface to ssa_propagate From: David Malcolm To: Jeff Law , gcc-patches Date: Tue, 24 Oct 2017 20:57:00 -0000 In-Reply-To: <4b766dde-648f-97a4-7366-e38e0154f29d@redhat.com> References: <4b766dde-648f-97a4-7366-e38e0154f29d@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg01766.txt.bz2 On Tue, 2017-10-24 at 11:40 -0600, Jeff Law wrote: > tree-ssa-propagate.c provides a fairly generic engine to propagate > values through a lattice while in SSA form. The engine uses two > callbacks to allow passes to provide pass specific handling of > statements and phi nodes. > > The callback mechanism served us well in a C world. It is however > somewhat painful to have state in those callbacks without resorting > to > global variables or passing around void * objects which contain the > class instance pointer. > > For example, tree-vrp uses the propagation engine to compute global > range information. Its callbacks vrp_visit_stmt and vrp_visit_phi > and > their children read/modify a variety of tree-vrp.c statics such as > vr_data. > > In some changes I'm working on I'd really like to move vr_data into a > distinct class and avoid having direct accesses to the underlying > array. > > So the problem is how are routines like vrp_visit_stmt and > vrp_visit_phi > and their children supposed to access the class instance? > > One way would be to just add a void * argument to them and pass the > class instance around. Alternately we could leave the global > variable > in place and have it set up, checked and wiped clean by the vr_data > class's ctor/dtor. Both are valid and would work, but they're a bit > ugly IMHO. > > This patch takes another approach. It builds a simple little class > around ssa_propagate where the statement and phi visitors are virtual > functions. Thus clients can override the visitors *and* they'll get > a > class instance pointer. > > I haven't gone hog wild with C++-ification, basically just enough to > get > the class around ssa_propagate and its children which are going to > need > to pass down the class instance to the virtual functions. There's a > lot > more that could be done here. > > As you can see the client side changes are pretty minimal. They just > derive a new class from ssa_propagation_engine to provide their > implementations of the statement and phi visitor. More importantly, > they can hang data off that derived class which we'll exploit later. > > There will be a similar patch for the substitute_and_fold which has > callbacks of its own. > > Bootstrapped and regression tested on x86_64. > > The ChangeLog makes the patch look huge. But it's actually > relatively > small and the client side bits are repetitive. > > OK for the trunk? > > Jeff Looks like you forgot to attach the patch. Dave