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

[Daniel Berlin <dberlin at dberlin dot org>]

> It helps immensly. If you call insert and the iterator value is NULL,
> you are adding a statement to the end of the basic block specified in
> the iterator.
But you haven't explained *how* you add the statement.
You don't have the place to link it to in the actual tree structure.
> >
> If the iterator points to a NULL, you add the statement to the end of
> the block, regardless of whether you are inserting before or after.
empty_stmt_nodes are their own blocks in the case i'm talking about..
The question is how to insert before or after them.

> The only way you get a NULL pointer in the iterator is if:
>   a) the block contains nothing but empty_statement_nodes. In this 
> case,
> its irrelevant where you stick the instruction, it'll be the only one 
> in
> the block, so appending it to the end of the block works for both 
> insert
> cases.
No it doesn't, because you still need to *put it somewhere in the tree 
structure*.
Adding it to the bb is easy.
Linking it into whatever the hell tree the empty_stmt_node is the 
operand or tree_chain of is *not*.
Remember that adding it to the bb without linking it to the underlying 
tree structure doesn't *do anything*.
> Im not sure where your problem lies.
In implementation.
You don't seem to understand.

Let me make it concrete.

Given a tree structure like

COND_EXPR
	<arg 1> whatever
	<arg 2> whatever
	<arg 3> empty_stmt_node

each arg will end up being it's own bb.

Thus, you will end up with

bb 2:
	head_tree_p: The COND_EXPR
	end_tree_p: The COND_EXPR
....
bb 6:
	head_tree_p: &empty_stmt_node (which is *not* &TREE_OPERAND 
(COND_EXPR, 3), it's &global_trees[empty_stmt], since empty_stmt_nodes 
are *unique*)
	end_tree_p:  &empty_stmt_node

How does one, given only this information, actually perform an 
insertion or replacement in BB 6? Not "add it to the end or begginning 
of the bb". That part is easy.  The insertion functions have to link 
this stuff into the tree structure, too, however.

You have no idea that the empty_stmt_node is really from the COND_EXPR 
in bb 2 (You can make it more complex such that walking predecessors to 
insert doesn't work by introducing another COND_EXPR with an 
empty_stmt_node arg in one of the two non-empty arguments to the 
cond_expr. Now you'll have two things that are predecessors of bb 6 
which could possibly be the magic link to the beginning of bb 6 we are 
looking for.)

Given:
I have no iterator that walked bb 2 to get to bb 6, and might contain a 
pointer.
I only have an iterator pointing to the end of bb 6, since that's where 
i want to insert.

*head_tree_p/end_tree_p will replace the unique empty_stmt_node, which 
is not what you want.

How does your solution help us to solve this problem?
It doesn't.
It provides no way to know that what we really need to do to insert in 
this block is to link to TREE_OPERAND (COND_EXPR, 3).

Actually adding stuff to the bb is easy, and was never the hard 
problem. It's linking it into the actual tree structure underlying that 
bb that's hard.

This case not only occurs, it occurs quite often, BTW.
It's not a hypothetical corner case.

Your solution just doesn't help.
De-uniquifying empty_stmt_node would.

That is the way i suggest we go.



> Andrew