[tree-ssa] Removal of gotos from cfg based ir
Andrew MacLeod
amacleod@redhat.com
Thu Nov 27 21:52:00 GMT 2003
On Thu, 2003-11-27 at 16:30, Zdenek Dvorak wrote:
> 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?
Quite simply because we have not all decided that it is more convienent
and that costs us nothing.
> > 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).
>
I dont want two different versions of the IL if we can avoid it. It
becomes a maintenance problem as the system becomes more complex.
Translating back and forth without very good reason is what we are
trying to avoid. Especially until we see how its so much better than
what we have.
> 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.
Its abosultely related, and central to the issue. Thats not for us to
decide, thats for the people writing those passes to decide. If they
dont want or need a CFG fopr whatever they want to do to the IL, we
ought not be forcing them to use one because we think its a good idea in
some other part of the compiler.
>
> > > > 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.
It wasnt me that said it, read the previosu paragraph:
> > > 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
"two different forms of rtl"..
Andrew
More information about the Gcc-patches
mailing list