Re: COND_EXPR lowering patch

[law at redhat dot com]

In message <1061855171.25084.327.camel@p4>, Andrew MacLeod writes:
 >On Mon, 2003-08-25 at 18:00, Zdenek Dvorak wrote:
 >> Hello,
 >
 >> 
 >> No, it will happen always -- you cannot create a condition in lowered
 >> for that would not be marked useful.
 >> 
 >
 >sure we can.
 >
 >
 >> 
 >> 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:
 >
 >
 >If we change the algorithm to not use parent_stmt, and instead use
 >control dependence information, I see no reason why this wouldn't be
 >eliminated.
Andrew -- I don't think this really matters.  With COND_EXPRs lowered,
detecting these kinds of cases becomes pretty trivial, either in
linearize_cond_expr or in a jump threader/forwarder.  


 >explicit GOTO's will never be marked as necessary by the algorithm. They
 >are implicited marked based on whether the edge remains or not.
 >
 >so If i understand what this is going to look like:
 >
 >BB 0
 >  if (a)
 >     goto x;
 >  else
 >     goto y;
 >
 >BB1
 >  x:
 >    (void)0                 // A
 >  goto z;
 >
 >BB2
 >  y:
 >    (void)0                 // B
 >  
 >BB3:
 >  z:
 >   stmt;
 >
 >Marking 'stmt' as necessary is not going to mark any control stmts as
 >necessary. When using control dependancies, only *conditional* control
 >flow on dependant edges gets marked, so the goto's are not.
In theory, you are correct.  However, both implementations I've worked
with have had to mark unconditional GOTOs as important and have done
so as soon as the target of the GOTO is marked as reachable/important.

The problem is something like this

 if (x)
   goto label1;
 else
   goto label2;


  label1:
    blah blah

  label2:
    blah blah.

The code starting at label1 is control dependent on the IF statement and
its edges, _not_ the goto label1.  So how precisely are you planning
to make sure that goto label1 is not deleted :-)

What we've done in the past is mark the incoming edges to a block
as important once something in the block becomes important.  That
effectively makes the gotos be marked as important (OK, so we bypass
the first step and mark the gotos as important once their targets
are marked as important).

But as I said in an earlier message, I'm starting to think this is all
a moot point.

Once you lower COND_EXPRs so that they merely contain a condition
and GOTO_EXPRs in their arms, it becomes quite trivial for either
linearize_cond_expr or a CFG based jump threader to remove
useless COND_EXPRs.  Meaning that we will not need control dependency
stuff in dce long term (either the real stuff or the stuff we fake
using control statement parents).

Jeff