Re: [tree-ssa] New regressions as of 2003-11-04

[Jan Hubicka <jh at suse dot cz>]

> In message <20031111173842.GT1729@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >> You didn't do this kind of analysis with the COND_EXPR lowering code
>  >> for example, and if you had done so you probably would have noticed that
>  >> were were missing many transformations that were working with the old
>  >> COND_EXPR code, but were not working with the new COND_EXPR code.
>  >
>  >Problems of this type are really bad.  There are numberous examples ofV
>  >this (the problem where tree-SSA assumes that RTL code is able to split
>  >live ranges comes into mind) Perhaps we can set up policy of requiring
>  >testcase for each new optimization added to ssa branch?
> You might be surprised, but I've actually done this for a number of the
> extensions I've made to the original dominator optimizer. 
I found some (somehow I assumed that the tests for given pass will be
called ssa-dom-*.  It is not quite complette, but good start :)
> 
>  >It took me considerable time to figure out what our dominator code is
>  >capable of and given the nature of problem the code solves, I guess the
>  >pass will envolve for a years adding various tricks and we should be
>  >curefull to not get another cse.c after 10 years again.  (this is not
>  >meant as complain about current code quality)
> Actually, I don't expect to be adding much more to the existing dominator
> optimizer.  If anything it's already become quite a bit larger than I
> ever imagined it would.  The focus will be more on cleaning up the 
> warts and improving readability rather than adding new features to the
> existing dominator optimizer.
> 
> Note that I do expect that we'll find other uses for the dominator walker,
> including new optimizations.    That was a large motivation behind 
> building a generic walker with the ability to record information during
> the dominator walk.  You can do an awful lot with that kind of framework.

Yes, having generic waler is excellent idea.  We may even organize
passes to be executed during single walk to avoid memory trashing, but
it would be nice to make them clearly separate.

At minimum I think we need some kind of reassociation/folding pass that
will be another big pile of code using this :)

Honza
> 
> 
> 
> jeff
>