Re: [tree-ssa] Minor code rearrangement

[law at redhat dot com]

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.

I can also certainly envision at least one optimizer that is going to want
to do a dominator tree walk, but which can not be merged with the existing
walks.  Fundamentally, it can't co-exist with the existing dominator
optimizer, but it wants to be able to use certain capabilities of the
existing dominator optimizer.

The framework is also meant to allow us to prototype new optimizers without
having to bolt them inside the existing optimize_stmt.  I can easily see
that code getting cumbersome to deal with if too much more is added to it.

Factoring that code will help, but from a maintenance standpoint trying
to lump everything together has certain disadvantages.  In fact, that was
the primary reason why we split out the existing dominator optimizer from
the SSA renamer.



 >As far as I can see currently optimize_stmt works like this.
 >It walks the tree once and does everything in one go.
Right.  And I'm not necessarily suggesting we change that.  Merely that we
separate the transformations we want to do from the dominator walk itself.

The decision to include a particular transformation in an existing walk
through the dominator tree is one that needs to be made on a per
transformation basis based on all the usual factors.

 >If you design such a generic  walker I would design it in a way that it 
 >gets a list of callbacks and calls them all in order while doing a single 
 >walk. 
 >
 >
 >This would be a bit more complicated because there could 
 >be side effects between the different callbacks, but likely much faster.
This isn't precisely what I'm doing, but you can get the same effect by
wrapping the two actions into a single subroutine and using the new
subroutine.

So let's consider transformations A & B and their set of callbacks.

I can run them separately by calling the dominator walker with A's structure,
then calling the dominator walker with B's structure.

If the two transformations can co-exist, I build a new transformation C,
in which C's callbacks just call A's routines, then B's routines.  Then
I call the dominator walker with C.

In fact, this is something I suspect I'll be doing shortly with the existing
dominator optimizations.   The existing dominator optimizer has several
distinct transformations & information recording capabilities.  We'll call
them A, B, C, D & E.  I also have another optimizer which I'll call X
which fundamentally conflicts with D & E, but which really wants to be
able to run with A, B & C.

So, I'll likely define two new transformations Y & Z.  Y will include
A, B, C, D, E and Z will include A, B, C, X.


It probably goes without mentioning that to be able to separate and combine
things like this, each of A, B, C, D & E need to cooperate via well
defined interfaces and not have their grubby little fingers in each
other's code.  Enforcing that kind of separation is also a good thing
long term.

Jeff