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

[Andrew MacLeod <amacleod at redhat dot com>]

On Fri, 2003-11-14 at 10:17, Jan Hubicka wrote:
> > On Fri, 14 Nov 2003 07:58:01 +0100, Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote:
> > 
> > > Consider a basic block that ends in statement causing an exception.  You
> > > cannot redirect the outgoing fallthru edge without creating a new basic
> > > block.
> > 
> > Perhaps we could decide not to put the trailing goto in a new block.
> This is the idea of shadow blocks SUIF have.  But how better it is than
> not having the problematic GOTO at all?
> The reason why SUIF goes this way is the fact that they wanted to not
> break legacy code that does not know about basic blocks.  They are
> mentioning as plan for future to remove the shadowing  We don't have
> such legacy code, why would we want to go for this?
> 
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?

Andrew