This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Re: PATCH: [gcc3.5 improvement branch] Very Simple constant propagation


In message <20040116152149.GB26819@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >Yes, that make sense.  About keeping tree-ssa-dom under control, would
 >be possible (make sense?) to decompose existing dominator optimization
 >into "set of optimizers called from dominator walk routine".
The dominator walker shouldn't have that kind of structure.  It should
not in any way know the details about what's happening in the routines
it calls.  The dominator walker's responsibility is to call the appropriate
callbacks and manage a freelist of block local data structures (and it
only knows the size of the block local data area).

For the kind of scheme you propose the dominator walker would call
a generic routine (say dom_opt_walk_stmts).  dom_opt_walk_stmts would
then cprop_stmt, eliminate_redundant_exprs, etc etc.

That kind of a design is ultimately where the code is going.  The next
step is to further dis-engangle the code inside tree-ssa-dom.c.



 > Ie make
 >each optimization go to separate file with structure dscribing it
 >(having callback for initialization/freeing/optimizing given stmt and
 >size of local datastructures) that gets called from the tree-ssa-dom.c.
I think you're going to find that is unmanagable.  There are important
interactions between these optimizers that you need to keep.  

 >The tree-optimize is more or less organized as two passes done in
 >sequence - first is cprop, other is redundant expression ellimination.
 >There is no corelation in between these two passes except for the fact
 >that they needs to be executed in order.
Err, no.


 >I would like also the value range propagation/nonzero propagation to
 >happen to be available in isolation too, so they can be easilly used by
 >the future expression folding/tree combining/reshaping pass.  (we
 >currently have duplication in between fold-const/tree-dom logic and if
 >we implement fully global VRP, we will have such things three times)
The fold-const code is solving a different problem than what is being
solved in the dominator optimizer.  Trust me.  I looked long and hard at
whether or not I could use the existing of fold-const range checking code.

A fully global VRP needs to be based on the CCP optimizer (which needs to
be generalized much like we have started for the dominator optimizer).
Similarly a fully global zero/nonzero tracking also needs to use the
CCP engine.

In both those cases there are bigger infrastructure issues to solve.


Jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]