[tree-ssa] edge insertion/split problem

law@redhat.com law@redhat.com
Tue Jun 17 00:28:00 GMT 2003


In message <Pine.LNX.4.44.0306162209080.23540-100000@wotan.suse.de>, Michael Ma
tz writes:
 >How can both be fall-thru?  Fall-thru is an edge whose head transfers flow
 >to the tail by a non-jump.
Very easily :-)  Though I'm as much to blame for the confusion -- I thought
we had decided to drop the "fall-thru" usage a while back because of
this kind of confusion.  Then I go and use the terminology in this thread.
Shame on me.

This is (yet another) artifact of our container representation -- certain
jumps are implicit via their containers.  The example most used in relation
to tree-ssa and implicit jumps is the jump at the end of a LOOP_EXPR back
to the start of the loop.  No such GOTO_EXPR actually appears in the IL,
but an edge does appear in the CFG.

COND_EXPRs, SWITCH_EXPRs and the various exception handling expressions
have edges which are implicit in the IL, but explicit in the CFG.  

 >That's by definition only possible for one of
 >the predecessors of a block.  I.e. one of either 9 and 7 already has to
 >have a jump insn at the end.  Even if 9 is empty one of the edges has to
 >be non-fallthru, at least conceptually.
You're absolutely correct in the RTL world.  Things work differently in
tree-ssa.  

For example, we have a "fallthru" edge from both arms of a COND_EXPR
to the statement following the COND_EXPR if they don't end with explicit
jumps elsewhere.  "fallthru" really means there's no further statements
at this statement nesting level and flow continues at the next
statement after the current nesting's parent.


 >Your notion of nested trees which can involve control transfer is at root
 >of all this confusion, as it seems to me that this creates the funny
 >problem of multiple fall-thru predecessors of a block.  It's simply
 >impossible to have such.  Similar for all the other problems you were
 >discussing over the last weeks dealing with critical edges and edge
 >splitting.  Those are long solved with a normal CFG.
I think everyone agrees that having a nested statement structure causes
a set of problems.  I don't think anyone is suggesting we're always going
to have a nested statement structure.  I think the only question is when
when we not have a nested statement structure :-)

My gut feeling is to keep it until we've merged with the mainline and
make losing the nested structures the top priority for the tree-ssa
team once we're merged with the mainline.

However, there's also the possiblity we're going to have to tackle this
problem as part of cleaning/simplifying up the tree->rtl process, in
which case it's likely to happen before merging with the mainline.

jeff



More information about the Gcc mailing list