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.

Yes, this is how I do imagine it.  I don't think we need to change
dominator walker itself, just we can have something more restrictive for
purpose of doing basic dominator optimizer pass.
> 
> 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.

I see, so nothing new from my side :)
I think actually moving things into multiple files would help too.  It
makes it much easier for someone who don't know the code to make sense
of what is all the helper code about.
Is there some major reason to keep jump threader in the same file?

>  > 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.  

What particular interactions you have in mind?
In the case we restrict the optimizers to examine single statement at a
time, we will maintain same behaviour as if the optimizers were done in
sequence.  I am not sure how maintainable this is.

>  >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.

I didn't have the existing fold-const range checking code in mind,
rather the existing predicates like tree_expr_nonnegative_p that can be
subsumed by it.  Combine.c also has nonzero_bits and similar predicates
that can be generalized into dataflow like scheme.

There are a lot of places we can use this infromation for algebraic
simplification.

It can be nice if fold-const, currently doing this locally were able to
communicate with tree-ssa-dom and possibly other passes having global
information available.  I believe it is possible to reach by unifying
these implementations. (not across RTL world, just inside trees, but I
think we would find use for nonzero_bits in fold-const too)
> 
> 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.
Yes, that is what I am trying to get into.
We can have dominator based engine, CCP based engine and local
expression engine and we could theoretically have pluggable analysers 
to any of these depending how hard work we want to do.

The idea of doing things in parallel in some limited scenarios is just
secondary.  Primarily I would like to attempt to unify code in between
these passes.

Honza
> 
> 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]