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] Removal of gotos from cfg based ir

On Fri, 2003-11-14 at 10:17, Jan Hubicka wrote:
> > On Fri, 14 Nov 2003 07:58:01 +0100, Zdenek Dvorak <> 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..


	call foo(blah, blah, blah)


	ABNORM (call foo (blah, blah, blah))  (fallthru, 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?


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