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, and gsi_step_bb

On Friday, November 29, 2002, at 10:31  AM, Diego Novillo wrote:

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

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.

Which is the bane of SSAPRE's current existence, and what i was trying to show Andrew is the "hard case" for insertion that adding things to the iterator doesn't help.

Special casing it just seems to make things ugly. The problem only occurs because it's already a special case. It's a unique node.

Making it non-unique (we could just add another thing to the tree_node union that is a structure *only* containing the tree code if you are concerned about memory) would solve the problem without having to special case it (since &empty_stmt_node would now be the right place to insert/replace).


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