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 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
> 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
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.