Re: [tree-ssa] RFC: Making control flow more explicit

[law at redhat dot com]

In message <20030809174318.GA31964@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >Hello,
 >
 >I have spent a few hours thinking about the issue and I now think there
 >might be a way to split the patch into smaller ones (perhaps also not
 >seeing the code for a day helped :-). The proposed splitting (numbers
 >in brackets mean my estimate on size of the change):
Good.  Conceptually, you can break things down by dealing with each of
the control structures individually.    Ie, kill LOOP_EXPRs, then 
SWITCH_EXPRs, then COND_EXPRs, etc etc.


 >1) elimination of LOOP_EXPRs [500] -- a few lines in gimplification, removal
 >   of references to them in tree-*, plus loop note regeneration just
 >   before loop header copying
Yup.  This one should be relatively easy.  In fact, I suspect you'll
end up removing more code than you write :-)

 >2) lowering of SWITCH_EXPRs and COND_EXPRs (so that their branches are
 >   just gotos) [500-1000] -- a change to gimplification, cleanup + a few chan
 >ges in optimizers
I'd recommed splitting this up into two different hunks as well.  One
which deals with SWITCH_EXPRs, the other which deals with COND_EXPRs.  Note
you want to make sure that whatever you do with COND_EXPRs doesn't regress
the code we present to the RTL optimizers -- we're actually at a point
where we typically present the RTL optimizers with *fewer* jumps than
without gimplification -- largely by being smarter about not creating
silly jumps.

 >3) replacing COMPOUND_EXPRs with double-linked chain of statements [500-1000]
 > --
 >   mostly changes to block iterators + places in code that rely on the
 >   fact that the whole function tree is kept, and final pass that
 >   regenerates COMPOUND_EXPRs
I've always wanted double-chaining and removal of the COMPOUND_EXPR wrappers
so no arguments from me.


 >4) moving BIND_EXPRs and exception handling constructs to their own tree [200
 >0]
 >   probably the most complicated step; some changes to iterators, many
 >   to cleanup, final pass to move structures back.  This is basically
 >   equivalent to the core of my current patch, I will try to think more
 >   on how to make this step less painful.
This is going to be bloody ugly.  I'd postpone this until last :-)


 >5) rewrite of make_edges [1000] -- especially eh edges are created in a
 >   weird way currently, IMHO.
The plan has always been to lower TRY_FINALLY into TRY_CATCH, we just
haven't gotten around to it yet.


jeff