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: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?
> 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
Im a little unclear what you are trying to explain to me :-)