Re: [tree-ssa] empty_stmt_nodes, deleted statements, iterators, and gsi_step_bb

[Diego Novillo <dnovillo at redhat dot com>]

On Thu, 28 Nov 2002, Andrew Macleod wrote:

> The easiest thing to do to solve that problem would be to make the
> iterator have 2 words, the stmt pointer and the basic block it belongs
> to. This would simplify many things I think, but it does have the
> drawback of passing a couple of words around as an iterator instead of
> just one. I doubt thats a huge deal, especially since a lot of routines
> which operate on interators are inlined. Perhaps there is a better
> option.
> 
I think we may not need to have the two words.  When we replace a
statement with empty_stmt_node, we do not really affect the
chaining structure.  So, if you are removing a statement in a
COMPOUND_EXPR, you only replace its 0th operand.

This means that even if the block is empty, gsi_start_bb sets the
iterator to the BIND_EXPR or COMPOUND_EXPR that holds the
empty_stmt_node (if it doesn't, it should).  You can always get
the block from that node.

The only real problem is the silly latch block that the CFG
builder creates for loops.  That block has no ties to the
program.  Its head_tree_p and end_tree_p are empty_stmt_nodes
that the builder stupidly puts in.

Maybe we could to teach gsi_insert_* about it.  What I'm thinking
is that when dealing with a latch block:

1- If the block really is empty, go to the loop entry block, and
   insert after its head_tree_p.

2- If the block already contains a statement, just do the usual
   insertion.


Diego.