Re: [tree-ssa] Minor code rearrangement

[Daniel Berlin <dberlin at dberlin dot org>]

On Oct 2, 2003, at 2:53 PM, law@redhat.com wrote:

> In message <m34qyrwlgv.fsf@averell.firstfloor.org>, Andi Kleen writes:
> > law@redhat.com writes:
> >
> > > Long term what I want to see is the ability to call a dominator 
> > > walker
> > > with a structure containing callbacks and state.  Then we'd share the
> > > walker between SSA rewriting and existing dominator optimizations.  
> > > That
> > > would also provide the framework to allow us to plug in other 
> > > optimizations
> > > around a dominator walk.
> >
> > Just a thought.
> >
> > Assuming gcc performance is mostly limited by memory latency in 
> > walking
> > structures.
> >
> > Then using walker functions for every sub optimization that walks
> > the whole tree for each transformation would be slower than having
> > a central walker that walks once and applies all applicable 
> > transformation.
> I'm not suggesting this.
>
> For example, the SSA renamer is just a walk through the dominator tree
> performing specific actions.  The current optimizations in 
> tree-ssa-dom.c
> are just a walk through the dominator tree performing a set of actions.
> There are part of PRE which I believe can also benefit from having this
> generic framework.

Yup.
That is, if you are walking in pre-order, that is. :P
It might be overkill, since we are just inserting into a list in 
pre-order, DT order.
We can technically just qsort the list with a smart comparison function 
that compares dominance order, and that might be faster than calling a 
walker (it's hard to say).

PRE also has a generic DFS of the SSA graph (in our case, the ESSA 
graph) variables that is uses to do it's dataflow in case anyone wants 
it.
With a trivial amount of work, it could be made to do it outside of PRE 
(the only think specific to ESSA it uses is the use list, which we have 
immediate uses for anyway on the regular SSA graph).

I never bothered because i never saw anywhere else that needs to do 
this.
We might in the future, however, depending on the optimizations.

--Dan