Re: [tree-ssa] cfg_remove_useless_stmts

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> This is Zdenek's code to implement a CFG-aware version of remove_useless_stmts
> 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.
> 
> The libjava problems I was having were due to a problem with the exec-shield
> capabilities in Red Hat's kernels.  Ugh.   Turning off exec-shield allowed
> me to get a regression test with libjava.
> 
> I've bootstrapped and regression tested this on i686-pc-linux-gnu.
> +   for (bsi = bsi_start (bb); !bsi_end_p (bsi);)
> +     {
> +       stmt = bsi_stmt (bsi);
> + 
> +       if (!var)
> + 	{
> + 	  bsi_next (&bsi);
> + 	  continue;
> + 	}
> + 
> +       /* If the THEN/ELSE clause merely assigns a value to a 
> variable/parameter
> + 	 which is already known to contain that value, then remove the useless
> + 	 THEN/ELSE clause.  */
> +       if (TREE_CODE (stmt) == MODIFY_EXPR
> + 	  && TREE_OPERAND (stmt, 0) == var
> + 	  && operand_equal_p (val, TREE_OPERAND (stmt, 1), 1))
> + 	{
> + 	  bsi_remove (&bsi);
> + 	  continue;
> + 	}

Can't this be told to tree-ssa-dom.c CSE instead of doing it so late?  Or
are we doing it on both sides? 
> + 
> +   /* Remove useless GOTOs from COND_EXPRs.  Other useless gotos could be
> +      removed by cfg cleanup, but it is not done currently, so do it here
> +      also.  */
Any testcase for this?  tree_try_redirect_by_replacing_jump should get
rid of GOTOs when it sees oppurtunity for this.
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.

Does the removal of GOTO_EXPR from one arm of COND_EXPR help?
(it needs little tweaking into my RTL expansion, but perhaps we simply
can avoid this step).
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?
> +   /* 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 :)

Honza