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

Zdenek Dvorak rakdver@atrey.karlin.mff.cuni.cz
Thu Nov 27 21:44:00 GMT 2003


Hello,

> Why should the program be represented differently during all these
> phases when we the representation we have works?

if it is more covenient and costs us nothing (I would not be surprised
if using the no-gotos representation was actually more efficient, but
definitely we don't lose anything), why not?

> We dont want a
> different IL during inlining or expansion in my opinion. 
> 
> If mudflap is going to insert code and branches and stuff after SSA
> runs, but before expansion, then its going to have to update the CFG and
> create new basic blocks etc etc etc. Isn't that true? If the inliner
> were to run after SSA, then it would have to deal with cfg edges rather
> than branches.. So Im not sure why it wouldn't impacts any of these.
> They wont see any GOTO's and labels,. just CFG edges.

There is always possibility to recreate the gotos (no, it does not bring
any performance problems; now we do exactly the reverse thing -- getting
rid of superfluous gotos -- anyway) for these stages, if it really is
that much a problem (although I don't see why should it be).

And in fact this is not quite related.  What is important for this is
whether we want to have cfg at these stages; if so, we will have to
update it anyway, regardless of whether the gotos are expressed
explicitly or not.

> > > Then when you are done with the block manipulations, call
> > > commit_block_replications() or somesuch thing, and any block which has
> > > more than 1 fallthru predecessor gets a label, and a goto is inserted
> > > into a new block following each of those preds.  You don't get new basic
> > > blocks forming all over the place until you specifically want them.
> > 
> > This is precisely what cfglayout mode is doing on RTL.
> > The problem is that we then effectivly do have two different forms of
> > RTL and we need to duplicate a lot of code depending on what form the
> > particular pass is using.  Thus we do have longer term plan of
> > converting all passes to CFGlayout mode as it make all passes either
> > easier or equally hard as they are now.
> 
> I dont think its the same thing at all. We dont have two forms of trees
> any more than we do when we are inserting stmts on edges. See below.

HUH? We do not have two forms of rtl, either.

Zdenek



More information about the Gcc-patches mailing list