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
