[tree-ssa] cfg_remove_useless_stmts

[law@redhat.com]

In message <20031113000612.GA7595@atrey.karlin.mff.cuni.cz>, Jan Hubicka writes
:
 >> 
 >> This is Zdenek's code to implement a CFG-aware version of remove_useless_st
 >mts
 >> which fixes 20030814-4 and 20030814-5.
 >> 
 >> The only changes since Zdenek's last publicly posted version are that
 >> it avoids munging GOTO_EXPRs when their associated edges are abnormal
 >> (say for a nonlocal goto).
 >
 >It would be nice to have testcases for the transformations done here :)
 >I am still having dificulties to understand what needs to be done here
 >and should not be done earlier.
There are for the more important of the transformations -- namely the
removal of obviously useless statements.  20030814-4.c and 20030814-5.c

What we don't have testcases for is the GOTO munging and verification
that empty statements are eliminated from the IL.

 >Any testcase for this?  tree_try_redirect_by_replacing_jump should get
 >rid of GOTOs when it sees oppurtunity for this.
None right now.  It's not even clear to me that this code should be
helpful anymore now that we're doing a better job at optimizing jumps
earlier in the tree-ssa optimizers.

 >Perhaps we are getting such a useless GOTOs from gimplification that
 >never get optimized out.  THen we should probably run this
 >remove_useless pass early as well.
We have code which optimizes jumps to jumps already.  Again, it's not
clear to me if the jump optimization part of this code is actually useful.


 >Does the removal of GOTO_EXPR from one arm of COND_EXPR help?
It does leave one less arm for the expanders to deal with -- and they
have some intelligence to know that if one arm is empty that they
can optimize the initial RTL they generate.

 >I tought the gimple gotos are always supposed to have both arm gotos.
 >What happens when the optimized function body gets inlined into another
 >gimple body?
An excellent question.

 >> +   /* The statement does nothing, remove it completely.  */
 >> +   if (!n_rem_gotos)
 >> +     {
 >> +       bsi = bsi_last (bb);
 >> +       bsi_remove (&bsi);
 >> + 
 >> +       if (bb->succ->succ_next)
 >> + 	abort ();
 >> + 
 >> +       bb->succ->flags &= ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
 >> +       bb->succ->flags |= EDGE_FALLTHRU;
 >> +     }
 >THis can be executed only for COND_EXPRs where both arms get nullified,
 >right?  This should be cared of by cfg_cleanup unless something is wrong
 >with it.
 >
 >Thanks for sorting this out.  I really apprechiate seeing CFG valid
 >after de-ssa pass now :)
I'm pretty sure that code can be reached for an empty statement node
and the effect is to remove the empty statement node from the IL
(which results in less code for the expanders to deal with as well as
fewer statements to save for inlining).

jeff