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 <20040116122022.GA8121@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >> My question is does this belong in dom at all.  While we might want to
>  >> do it as part of a dominator walk or other transforming pass, I don't
>  >> see that it needs to live in the current dominator optimizer.  Unless
>  >> it's like to expose lots of additional optimization opportunities.
>  >
>  >I wonder where to place it right now.  Do we have some other pass that
>  >walks the whole chain where this can be placed?
>  >Or shall I invent new one.  I think this can be run just after profile
>  >is constructed and it can be place where our current profile value
>  >transformation pass should be placed, so perhaps I can simply start
>  >this.  If this sounds sane, I can implement the new pass this week.
> Start with a new pass.  It's not the end of the world.  If we find
> that there's significant benefit from being integrated with the existing
> dominator optimizer, then we can combine them.  But in general I want to avoid
> adding new styles of optimization to the existing optimizer -- it's getting
> a little bit out of control.

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

It is just cosmetic change, but it can enforce interfaces in between
individual components making it easier to rewrite/replace/fix them in
separation.

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)

Walking more this thread, considering constant propagation, the
difference in between real constant propagation and what dom does is
that dom does not do the full dataflow and just assume "varying" in
cases there are forward references.  Perhaps it will be even possible to
describe such optimizations by structure having callback for propagation
data and run same implementation either in such a fast mode (like dom
does) or in busy mode like CCP does.

In the past I was experimenting with such local optimizer megapass on
RTL that does multiple existing local passes (constant propagation, copy
propagation, CSE, counting for dead code removal, initializing alias
analysis, reg-scan) from single driver possibly in parallel depnding on
the flags and it appeared to work as long as the optimizers were
strictly restricted to modify the current instruction they are passed
to, or possibly the following instructions.  For RTL it is bit nasty to
enforce this invariant for some of ugly side corners, like CC0 and/or
libcalls, but for trees this may be workable.  I guess you know better
than I do.

I got this working on RTL, but I was waiting for Zdenek's reorganization
of rest_of_compilation to take place.  It never did, but now when we
have pass manager for trees, doing the same for RTL may be easier
(cloning Richard's design that seems to be more acceptable than what
Zdenek did)
I will try to propose patch for the new profile based optimization
tricks starting with this simple transformation.

Honza
> 
> jeff
> 
> 
> 


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