Re: [tree-ssa] Get rid of LOOP_EXPRs

[law at redhat dot com]

In message <20030822174828.GA6582@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak writ
es:
 >> Can you put the bsi_next_in_bb change into a separate patch
 >
 >yes I could; but given that it is just that one line, it would be
 >perhaps easier if you just imagined I did it :-)
In general, it's best to send unrelated patches as separate messages.  However,
since I've already got a test running with just this one patch installed,
I'll go ahead and take responsibility to break it out.


 >> The reason I ask is I'm not sure your change is sufficient to make the
 >> compiler safe when treating BIND_EXPRs as starting/ending blocks.  Consider
 >> what happens when we merge blocks and call replace_stmt with TP2 being
 >> a COMPOUND_EXPR.  That's going to create new BIND_EXPRs.  Those BIND_EXPRs
 >> can't create new blocks (because the block merging code assumes that one
 >> of the two blocks is going to go away).
 >
 >yes, this will have to be handled; given that everything seems to work
 >(as BIND_EXPRs usually are not seen), could this be solved in a followup
 >patch?
I'd prefer not to handle it as a follow-up since failure to handle these
cases can result in aborts and possibly even incorrect code.  That's
from firsthand knowledge of poking at BIND_EXPR removal briefly.

 >> I also think this code is going to run afoul of SWITCH statements.  You're
 >> going to have an unreachable bock at the start of the switch body.
 >
 >that's why this change:
 >
 >	(remove_unreachable_block):  Work for empty blocks.
 >
 >is here.
OK.

What I'm hoping to do is finish testing the bsi_next_in_bb fix and then
re-test the LOOP_EXPR removal patch and hopefully get it installed
(LOOP_EXPR removal is more of a hot button for me than BIND_EXPR removal :-)

Jeff