This is the mail archive of the
mailing list for the GCC project.
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 <email@example.com> 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?
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.
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.