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

[Andrew MacLeod <amacleod at redhat dot com>]

> 
> Oh ho! 
> 
> Actually, yes, we may not need the extra word. The bug that was showing
> up is a bug in the cfg builder make_blocks():
> 
>
This appears to fix the gsi_step_bb() issue I had, but it still doesn't
address the original issue that I was interested in. Perhaps the issue
is moot now.

What I was trying to do was make it so that you never see an
empty_stmt_node when iterating through a block.  Is that goal still
worthwhile, or should we just accept that we are going to see these
types of nodes and check for them. Im not particularly fond of that
concept. I dont think you should ever see one.

If it is worthwhile, then we still have the issue of how to determine
the basic block if a block has nothing but empty_stmt_nodes.
gsi_start_bb() will end up setting iterator.tp = NULL_TREE, so you don't
even have the container in the iterator to look for the block. Thats the
original reason I proposed the second word. In particular, to
facilitate:
    iterator=gsi_start_bb (bb)
    gsi_insert_after/before(iterator, stmt);
when there are no statements of interest in bb.

I suppose we might be able to *always* set the container, and have
gsi_stmt(i) return NULL_TREE instead of the empty_stmt_node... That is
pretty much the functional equivilent.

hmm. All the changes I had to make are mostly dealing with first_stmt()
and last_stmt, which the semantics don't change for. In fact,
gsi_step_bb is the only routine I may have to change... 

let me ponder this and look at the code I have a bit more. I have a
sense that I can make this all transparent without the additional word
now that the container is getting the right basic block value.

Andrew