COND_EXPR lowering patch

[law@redhat.com]

In message <1061923315.2168.130.camel@p4>, Andrew MacLeod writes:
 >On Tue, 2003-08-26 at 14:31, law@redhat.com wrote:
 >>
 >>  >I'd also be tempted to try to call that final DCE from within
 >>  >SSA->Normal once we've eliminated PHIs, but before we've actually
 >>  >written the program back to normal form... Then we could get everything
 >>  >thats really dead at that point...
 >> We run DCE just before the conversion from SSA to normal form.  I would not
 >> expect that SSA to normal exposes any dead code.  Then again, I could be
 >> wrong.
 >> 
 >
 >It can expose dead control flow, plus anything which ripples from that,
 >but perhaps we get that later? 
We get a goodly amount of that via the useless statement eliminator.

 > We currently cant eliminate flow which has a PHI node in the post
 > dominator.
That's no longer entirely correct :-)   There are cases where you can
eliminate the flow even when there is a PHI in the post dominator.  We've
been doing it in linearize_cond_expr for a month or so.  Basically if
incoming edges to the PHI from each arm of the COND_EXPR have equivalent
arguments, then we can remove the COND_EXPR and collapse the two PHI
alternatives into a single alternative.  This happens often enough to 
matter :-)


 >SSA->Normal eliminates all the PHI
 >nodes, so these empty control structures become fair game if the
 >elements of the PHI node coalesced together and no code was inserted
 >into the empty control blocks....
OK.  I see.   I'm not sure how much this happens now that we collapse
useless control statements, even when there's a PHI in the pdom.  If it
still happens, then, yes I see how it would be useful.

Jeff