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

[Jeff Law <law@redhat.com>]

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