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
