Re: [tree-ssa] cfg_remove_useless_stmts

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > 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? 

The problem is that this fixes up things that are created by un-ssa
pass.  Concretely consider

if (s == 0)
  s = 1;

This becomes

if (s_1 == 0)
  s_2 = 1
s_3 = phi (s_2, s_1)

Constant propagation creates

if (s_1 == 0)
  ;
s_3 = phi (1, 0)

Un-ssa makes

if (s == 0)
  s = 1;
else
 s = 0;

from it.

> > + 
> > +   /* 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.

But it is not called for example in case when we remove all
(unreachable) basic blocks between the goto and its target label.

> Does the removal of GOTO_EXPR from one arm of COND_EXPR help?

No idea; I just copied this from the remove_useless_*

> (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?

Nothing much.  The invariant you mention is only assumed in a lowered
gimple form (i.e. after lower_function_body call).

> > +   /* 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.

Yes it could; no it is not, since cfg_cleanup is not run after un-ssa.

Zdenek