From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52799 invoked by alias); 24 Oct 2017 17:40: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 52782 invoked by uid 89); 24 Oct 2017 17:40:43 -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=visitors, served, theyll, they'll 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 17:40:42 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 247377EAA1 for ; Tue, 24 Oct 2017 17:40:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 247377EAA1 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-112-29.rdu2.redhat.com [10.10.112.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9C38E5C552 for ; Tue, 24 Oct 2017 17:40:39 +0000 (UTC) To: gcc-patches From: Jeff Law Subject: [RFA][PATCH] Provide a class interface to ssa_propagate Message-ID: <4b766dde-648f-97a4-7366-e38e0154f29d@redhat.com> Date: Tue, 24 Oct 2017 17:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg01737.txt.bz2 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