Re: COND_EXPR lowering patch

[law at redhat dot com]

In message <20030825173317.GD15168@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >Hello,
 >
 >>  >The main showstopper seems to be the tree-ssa-dce; after this change
 >>  >it cannot work in the current form (resp. it could, but since most
 >>  > of the interesting control flow will then be expressed by explicit
 >>  > gotos, it would be useless).
 >> Actually, as I've stated before, I believe the existing tree-ssa-dce
 >> should continue to work, even after you've lowered COND_EXPRs because
 >> we mark the parents of an incoming GOTO_EXPR as being necessary.
 >
 >yes, it will work, but it will be completely useless.  Consider
 >
 >if (a)
 > {
 > }
 >else
 > {
 > },
 >
 >written as
 >
 >if (a)
 >  goto _then;
 >else
 >  goto _else;
 >
 >_then:
 >goto _end;
 >
 >_else:
 >_end:
 >
 >as the code works now all statements here including the condition
 >will be marked as useful.
And we care because? 

Yes, this kid of thing does happen, but not that often.  Plus we already 
have code to handle it and collapse the IF away when both arms just jump to
the same location.

However, what I have failed to consider is that if we keep the COND_EXPR
straightening code currently in tree_cleanup_cfg, and install your patch
to flatten COND_EXPRs, then we may be able remove all the control dependency
stuff in code in dce.c.

When I first attempted this on the assumption that if DCE killed all the
statements in both arms of a COND_EPXR that we should easily be able to
determine the COND_EXPR itself was uselss during cleanup_tree_cfg the
typical cases we missed looked something like


if (a)
  {
    {
      {
         (void)0
      }
    }
  }
else
  {
    {
      {
        (void)0
      }
    }
  }

[ Possibly with multiple empty statements strung throughout the arms. ]

Ie, DCE deleted all the executable statements, but since I had turned off
control statement removal, DCE left in the skeleton with the COND_EXPR.  
And since the arms were trivial empty statements, linearize_cond_expr couldn't
do anything with it.


Now, if we keep linearize_cond_expr with your COND_EXPR lowering code we
would see 

if (a)
  {
    (void)0
  }
else
  {
    (void)0
  }
      
Which linearize_cond_expr knows how to remove (and for which lazily build
pdoms -- so the vast majority of the time we don't have to pay the cost of
building pdoms.


So what we _may_ want is your COND_EXPR lowering code, removal of the
control structure stuff in tree-ssa-dce.c and keep linearize_cond_expr.

Jeff