[tree-ssa] COND_EXPR lowering preview

[law@redhat.com]

In message <1062013399.4452.7.camel@frodo.toronto.redhat.com>, Diego Novillo wr
ites:
 >On Tue, 2003-08-26 at 14:53, Zdenek Dvorak wrote:
 >> It disables control structures removal in dce; this also has to be
 >> handled separately.
 >> 
 >What does this have to do with COND_EXPR lowering?
A lot actually.  If you have lowered COND_EXPRs, then there is very little
value in tracking control dependencies in DCE.


 >> It removes linearization from cfg cleanup, since the half of it
 >> is redundant with the patch and the rest contains several
 >> serious bugs (the most important one being that it uses merge_blocks; this
 >> function contains more bugs than correct code :-(
 >> 
 >Test cases?  Better yet.  Fixes?  Generalizations like this one are
 >hardly useful.
As for cfg cleanup, I'd really like to see some analysis on both the
bugs and with/without.  ie, I don't want to start taking steps backwards
in terms of performance.  Simply claiming its unncessary isn't enough.

Similarly for merge blocks.  Analysis please.


 >> Some possibly useful cleanups were removed from
 >> remove_useless_stmts_and_vars; this function is not suitable for
 >> work over unstructured code.
 >> 
 >Again.  Please separate this.  It has little to do with COND_EXPR
 >lowering.
Actually remove_useless_stmts_and_vars is supposed to work with unstructured
code.  If it does not, I'd really like to see some analysis why.

 >> COND_EXPR lowering is being done in gimplification; if you like/dislike
 >> it, cry -- I personally have no opinion whether it should be done there
 >> or somewhere later.
 >> 
 >I still think we should separate this from the gimplifier.  We should
 >probably have a single lowering pass that runs immediately before we
 >build the flow graph.
I don't see the value in having it separate.  All that does is force 
another walk over the statements, which seems awful wasteful.  I'd
prefer to see this lowering happen during gimplification.

jeff