Re: [tree-ssa] Removal of gotos from cfg based ir

[Andrew MacLeod <amacleod at redhat dot com>]

On Fri, 2003-11-14 at 10:37, Jan Hubicka wrote:
> > On Fri, 2003-11-14 at 10:17, Jan Hubicka wrote:

> > Why not wrap any trapping instruction like this in a new IL expression
> > which woirks like a COND_EXPR does..
> > 
> > so 
> > 
> > 	call foo(blah, blah, blah)
> > 	fallthru_code
> > 
> > becomes
> > 
> > 	ABNORM (call foo (blah, blah, blah))  (fallthru, trap_label)
> > fallthru:
> > 	fallthru_code
> > trap_label:
> > 	trap code
> > 
> > 
> > Then any block ending in an ABNORM code is expected to have 2
> > GOTO_EXPR's just like a COND_EXPR, so when you duplicate the block, you
> > won't get a new block, nor any unexpected side effects. Duplicating the
> > ABNORM expression takes care of it.
> > 
> > Then if/when we dont care any more, you can expand the ABNORM expression
> > into a GOTO if needed.
> > 
> > Would that take care of the problem?
> Yes, 
> However it breaks assumption that control flow instructio is the last in
> basic block.  Inserting code to the end of basic block is very common
> optimization and we don't want to make it more dificult.

Isnt adding code after the call going to be in a different basic block
anyway? so Im not sure what you mean here, why its mor difficult.

The ABNORM expression *is* a control flow instruction, as far as anyone
is concerned, because it means GOTO fallthru_label, or GOTO trap_label
in some unknown way,.
 
> You may want to shadow the GOTO out of basic block (similary you may
> want to shadow the labels out, so you can easilly insert to the
> beggining of block).  But that introduces new pointers to the basic
> block structure.  It is my second-favorite sollution though.
> 
Im a little unclear. If you wanted to shadow them so you could insert to
the beginning of a block, wouldn't you have to duplicate the fallthru
block anyway? 

Im a little unclear what you are trying to explain to me :-)

Andrew