Re: [RFA][PATCH] Provide a class interface to ssa_propagate

[David Malcolm <dmalcolm at redhat dot com>]

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