COND_EXPR lowering patch

[law@redhat.com]

In message <20030825220038.GA21323@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >Hello,
 >
 >>  >as the code works now all statements here including the condition
 >>  >will be marked as useful.
 >> And we care because? 
 >
 >because why would we want to have a code that does not anything at all?
A later pass will trivially clean this up.  I don't see a need to work hard
to remove it or to worry about it all because I already know it will go
away.

 >> Yes, this kid of thing does happen, but not that often.
 >
 >No, it will happen always -- you cannot create a condition in lowered
 >for that would not be marked useful.
Regardless, we already have code which will make that construct go away. So
I'll ask again, why do we care if DCE marks these things as useful.  We're
going to zap the entire bloody thing soon enough.


 >> Plus we already 
 >> have code to handle it and collapse the IF away when both arms just jump to
 >> the same location.
 >
 >yes, this is exactly why I don't consider the condition removal part in
 >the optimization critical.
It is important if you haven't flattened COND_EXPRs.  Once the COND_EXPR is
flat, then I could care less if DCE marks this stuff as useful or not because
I know a later pass will make it go away -- trivially.


 >> 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 dependenc
 >y
 >> 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 could
 >n'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
 >>   }
 >
 >uh?  Then you probably have other idea about the shape "lowered
 >COND_EXPRs" should have.  In what I do, this would look like
 >
 >if (a)
 >  goto x;
 >else
 >  goto y;
 >
 >x:
 >  (void)0
 >goto z;
 >
 >y:
 > (void)0
 >z:
 >
 >> 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.
 >
 >well, in fact I don't like linearize_cond_expr very much.  Instead we
 >want jump threading (cfg cleanup version, i.e. over cfg cleanup only) +
 >a simplified version of linearize_cond_expr that will just cancel
 >conditions both of whose branches has the same target.
Whatever.  The point is that by lowering COND_EXPRs, we no longer have
to deal with control structures appearing as children of the COND_EXPR,
which makes detection and elimination of if (x) goto y; else goto y
trivial.  I don't care if we use linearlize_cond_expr or your jump
threading code.

I think we're violently agreeing.


Though given that I want to see us incrementally improve things, I do not
want to see a mega patch which does both changes at once.

In fact, I'd really like to slow the patches down and get resolution
on those which are already outstanding, starting with the LOOP_EXPR
patch.  I believe there is a single outstanding issue with it that
is preventing it from being installed (the gcov failures).  I'd really
like to see that resolved before submission of COND_EXPR lowering.


jeff