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

[Jan Hubicka <jh at suse dot cz>]

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

(for RTL this is hard to do because of target dependency, but for SSA we
should be able to deal with this - all we need is to add dump message
when transformation is done (that is usefull itself anyway) and check
for that message in dump)

Dominator pass is example of something where I would say we will get
great benefits from testing given the fact that most of the
transformations it can do can be done later by more generic pass, just
dominator code does them in faster way and early.

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)

Honza
> 
> 
>  >> Have you verifed that it does the right thing when the CFG isn't available
>  >> since this code is called before we build the CFG?
>  >
>  >No it won't -- I plan to leave the remove_useless_stmts_and_vars call
>  >before cfg creation as it is (trusting you that it is useful in some
>  >way), and just replace the call to it done at the end of tree-ssa
>  >optimizations.
> OK.
> jeff
>