Re: [tree-ssa] Get rid of LOOP_EXPRs

[law at redhat dot com]

In message <20030822172805.GA3407@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak writ
es:
 >Hello,
 >
 >here is the patch for the regressions removing LOOP_EXPRs would
 >cause.
 >
 >>  >2) In the following testcase it happens that start of BIND_EXPR is the la
 >st
 >>  >   statement of a block; when bsi_insert_after is called on it,
 >>  >   statement is inserted after end of BIND_EXPR block, which is far away
 >>  >   from the position where it should be, thus causing misscompilation.
 >>  >   Also reproducible with tree-ssa-branch using explicit gotos, testcase
 >
 >this in fact turned out to be a problem with bsi_next_in_block that in
 >this case returned the BIND_EXPR as a statement.
 >
 >The patch also makes the BIND_EXPRs to start/end basic blocks as Jeff
 >suggested.
 >
 >Zdenek
 >
 >	* tree-cfg.c (make_bind_expr_blocks, make_blocks, stmt_ends_bb_p):
 >	Create new block with start of BIND_EXPR.
 >	(remove_unreachable_block):  Work for empty blocks.
 >	(remove_bb): Don't remove BIND_EXPRs with reachable inner parts.
 >	(debug_tree_bb_n): New.
 >	(bsi_next_in_bb): Work correctly when the block ends with start
 >	of BIND_EXPR.
Can you put the bsi_next_in_bb change into a separate patch.

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

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.

I'd be very very interested to know if you bootstrapped the tree-ssa branch
with this change and ran the regression testsuite.

Jeff