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

[Jan Hubicka <jh at suse dot cz>]

> On Fri, 2003-11-14 at 05:40, Jan Hubicka wrote:
> > > Hello,
> > > > Could you give examples of your other points?  (creation of a basic
> > > > block when redirecting edges
> > > 
> > > Consider a basic block that ends in statement causing an exception.  You
> > > cannot redirect the outgoing fallthru edge without creating a new basic
> > > block.
> 
> > 
> > We do hit problem of implicity inventing new basic blocks on other
> > places too.  For instance we do delay edge splitting for this reason and
> > have very convenient machinery to temporarily emit instructions to
> > edges.
> > 
> > I've seen different techniques to deal with this.  Either you relax
> > fallthru edges to not follow to consetuctive blocks, like (as long as I
> > remember) Impact and RTL cfglayout mode does, or you do manipulation via
> > more complex API allowing you to temporarily break relations in between
> > CFG and code like MipsPro, or you hide the gotos in shadows of basic
> > blocks (relax definition of basic block) like SUIF does, or you do
> > everything in code based manner having CFG only for analysis, not for
> > manipulation (LLVM for instance).
> > 
> > I do believe that approach of making CFG part of the IL (not making IL
> > uncomplette) is the most consistent sollution and probably easiest to
> > deal with.
> > My next candidate would be the idea of shadow gotos, but I would preffer
> > to avoid it.
> 
> IF you are entering a part of the optimizer where you are going to do
> this kind of manipulation a lot,  why not simply change all FALLTHRU
> edges in the program to be explicit GOTOs until such time that you no
> longer need it?  Is this what LLVM does? Its seems like the most natural

This is not possible with presence of EH edges - trapping instruction
must be last in the block and you can not insert GOTO after it.

Honza
> way of dealing with the problem if its that sticky of an issue. then
> presumably cfg_cleanup will get rid of them all when you are done, if
> the blocks are indeed still consecutive.
> 
> Andrew
>