Re: [tree-ssa] Mainline merge as of 2003-04-06

[law at redhat dot com]

In message <20030410194619 dot GB2202 at tornado dot toronto dot redhat dot com>, Diego Novillo wr
ites:
 >If it's any consolation, I think I just reproduced the problem
 >with a COND_EXPR:
Not a great surprise, I was pretty sure it would be possible to create
a similar situation using just C code.


 >> If it should point to #2, then all these little fragments in tree-cfg.c
 >> must skip empty statements when trying to determine what NEXT_BLOCK_LINK
 >> ought to be to catch cases were a tree ends with one or more empty
 >> statement statements:
 >> 
 >>   /* Determine NEXT_BLOCK_LINK for statements inside the COND_EXPR body.  *
 >/
 >>   si = tsi_start (cond_p);
 >>   tsi_next (&si);
 >>   if (!tsi_end_p (si))
 >>     next_block_link = *(tsi_container (si));
 >> 
 >> Would skipping through empty statements in these loops potentially
 >> cause problems elsewhere?
 >> 
 >The interesting problem is what happens when we run out of
 >statements in the chain holding the COND_EXPR.  This means that
 >we should have every statement in the body know about
 >NEXT_BLOCK_LINK.
Sorry, I don't follow why every statement in the body would need to
know about NEXT_BLOCK_LINK.  It seems to me you replace the code above
with something like this:

  /* Determine NEXT_BLOCK_LINK for statements inside the body.  */
  si = tsi_start (expr_p);
  tsi_next (&si);

  /* Ignore any empty statements at the tail of this tree.  */
  while (!tsi_end_p (si) && tsi_stmt (si) == NULL)
    tsi_next (&si);

  if (!tsi_end_p (si) && tsi_stmt (si) != NULL_TREE)
    next_block_link = *(tsi_container (si));


The basic idea being to first skip any empty statements at the tail of a 
tree.  After skipping, if we are not at the end of the tree and we have
a real statement, then NEXT_BLOCK_LINK would be that real statement.  
Otherwise NEXT_BLOCK_LINK comes from the parent tree via the
next_block_link argument that's passed into these functions.


 >Seriously, though.  I think we should be compacting the
 >instruction stream as we go out of SSA.  Having the flow graph
 >make all these contortions to accomodate empty_stmt_node is just
 >not worth it.
Compacting the tree is probably a good idea, but my gut tells me that
there are probably going to be cases where getting rid of the empty
statement nodes may require some unpleasant contortions.

Jeff