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

[law at redhat dot com]

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. 

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



jeff