This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, 2002-11-28 at 20:49, Daniel Berlin wrote:
> >
> > The drawback is that if a block has no statements, its not as
> > convienient to add a statement.  ie, if we write a gsi_insert_after()
> > routine, its likely to be used something like this:
> >
> *if*?
> Diego's been promising one for a while, since SSAPRE needs it for 
> adding to blocks with empty statements (i've presumed it would know 
> what to do).

The if wasn't an 'if we ever write', it was a hypothetical 'if you were
to write one and it looked like this'. Certainly there will be insert
routines, we just haven't defined what they will look like yet.

> > gsi_stmt_interator i;
> > i = gsi_start_bb (bb);
> > ...
> > n = new_stmt(...)
> > gsi_insert_after (n, i)    /* or something like this.  */
> >
> > If there are nothing but empty_stmt_nodes in the block, gsi_start_bb
> > will set the iterator to NULL. So when it comes time to add the
> > statement, we don't even know what block we are adding this statement
> > to, let alone where....
> >
> > 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.
> What makes you think this helps?

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. 

> Because empty_stmt_node is unique, &empty_stmt_node is not the place 
> you want to link the statement to anymore, because it's really a 
> pointer to the unique empty_stmt_node (somewhere  in the global_trees 
> array).
> But that's what gets put in the head_tree_p/end_tree_p.
> Thus, bb->head_tree_p/end_tree_p can't be replaced just by 
> "*bb->head_tree_p = <whatever>"
> You end up replacing what empty_stmt_node means if you do that.
> I've done it.
> Look at the SSAPRE code, search for "FIXME: This can't be fixed without 
> the insertion machinery knowing what to do about it".
> Trying to get it right is *incredibly* ugly unless you just stop making 
> them unique, and thus, a special case.
> Remember that you still have to find where the heck to actually link 
> the statement into (remember the bb is on top of the trees, not in 
> place of it, so just putting it in bb->head_tree_p in this case doesn't 
> actually *do* anything to the code).

> To do this without de-uniqifying, you actually need a parent_tree_p for 
> bb's consisting of empty_stmt_node so you know where the actual 
> empty_stmt_node is linked
> I mentioned this to Diego a while ago, and he said he'd  worry  about 
> it later.

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. 
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
  b) you've iterated past the end of the block. Im not sure it makes
sense in this case, but for consistency we may want to allow it. If we
decide it doesn't make sense to be able to insert based on this
condition, you simply clear the BB field of the iterator when you
iterate past the last stmt. Then you can have the insert routine
complain because BB isn't set. 

If the iterator points to anything else, its a real stmt. By definition,
it'll never point to an empty_stmt_node. And I think we should skip
error_mark_nodes too.

Im not sure where your problem lies. 

> > 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.
> >
> > What does everyone else think? Any other alternatives for tackling 
> > this?
> > what other issues are there going to be?
> See above.
> It doesn't help in doing insertion after/replacement of empty statement 
> nodes, which is important.
> The cleanest way to do that is to actually de-uniqify empty_stmt_node, 
> rather than special casing them.
> Whether this means adding a EMPTY_EXPR/EMPTY_STMT tree code to compare 
> against (rather than pointer comparing empty_stmt_node), i'm not sure.

You will never be replacing an empty statement node, because you never
see one.....

You will insert_after() an empty_stmt_node, but I dont see why thats an
issue. It'll always be the last stmt in the block, and the iterator will
point to the compound_expr or whatever else contains the links to the
next stmt. If it doesn't you can clearly hunt for it since you know the
basic block and you know where the last stmt is. That would be a rare
case though I would think.

Remember you are inserting after an iterator, not a gsi_stmt(i) tree.

To simplify appending to the end of a block, we could also provide a
gsi_end_bb(bb) routine as well... That could be useful for that case,
but not much else :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]