This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, 2003-11-14 at 14:14, Michael Matz wrote:
> Hi,
> 
> On 14 Nov 2003, Andrew MacLeod wrote:
> 
> > > it is not now, either; to do exception handling, you must use such a kind
> > > of information.  And in fact, IL == statements + cfg even now -- you
> > > cannot reach statements without passing through basic blocks.
> > >
> > Why not? THe IL represents everything.
> 
> This is the basic disagreement I think.  But it's bad for the insn stream
Yes, I think this is the basic disagreement. 

> (I guess you mean that by "IL") alone to represent the program.  This is
> because control flow is a fundamentally different concept from simple
> insns which just have side-effects on data, at least if you want to
> implement a fast compiler.  Algorithms for control flow are different from
> those dealing with data effects.  Hence it's logical to capture the
> control flow in a structure which does not resemble any normal
> instructions, namely the CFG.

Yes, no one is arguing that we dont need a cfg, you build that as an
encapulation/summary of flow through the IL. The disagreement is whether
the cfg ought to be an integral part of the IL description or not. Like
every other data structure that the optimizers use, I think it ought to
be referred to for information, not used to drive the IL.

> 
> If you do that you have the problem of redundant information (because
> there are still those jump insns in the stream which have to be made
> consistent with the real representation, the CFG).  Ergo you delete them,
> and make them implicit.
> 
> Especially all algorithms dealing with control flow (loop optimizations,
> block ordering, trace scheduling, whatever) will be helped by that design.
> 

I dont see that its helps that much. There is a small amount of bookwork
required to maintain the stmt's in step with the CFG, but it certainly
doesn't seem to be very much,as long as the flow is explicit in the IL
(or insn stream if you prefer). 

If the original intention was to do this, we didn't even need to lower
the original container stmts, you just detach them when we build the
CFG, and let the CFG decide where everything is, and then reattach
things to the appropriate container when we destroy the CFG. That would
have been a much simpler way of getting there than going through all the
pain of lowering the stmt chain into a single list, then breaking it up.
It would have been much easier to convince me of this before we went to
all the effort of lowering the code. Some of us even discussed the
possibility of integrating the CFG a year ago when it was containers,
but lots of other changes were happening at the time. Now that its
lowered, I see even fewer reasons to do it.
 

> Note that it's not going to help to introduce magic wrappers around insns
> which transfer control, because those would _still_ be insns, which is
> exactly not the part of IL on which you want to do control flow changes.
> On the contrary, they just make the insn level of the IL more complicated.
> 
> I.e. the best way for the IL is to have insn stream _and_ CFG, without
> reduncancies between them.  In fact the IL would be conceptually cleaner
> and simpler if changed in the proposed way.
> 
And this is a disagreement. I dont not think its fundamentally cleaner. 
Lets remove certain restrictions we have today and allow the IL to be
written out to a file. I dont think we are going to want to write the IL
out as a stmt stream and a CFG, I think we want to write out a stream of
stmt's. nice straightforward and clean.  To do this at any point where
we have a CFG present under this scheme, we have to do convert to the
stmt stream. Sure, it can be done, but I dont see the point when its not
much effort to maintain the stmt stream intact.

I dont think the wrappers are a hack either. Its seems pretty clean to
me. It allows you to replicate blocks and such with little effort, and I
dont see what issues the cfg manipulation has left that is a big
benefit.

If you want to redirect an edge to another block which exists, you have
to change the label in the GOTO as well as move the edge instead of just
moving the edge.
If you create a new block and want to goto it, you have to add the goto
and the label. 
what else needs to be done? 


> Your argument with -O0 withoug CFG: I think that's a red herring.  For
> building SSA form you need a CFG anyway, so are you proposing to not even
> use SSA when -O0?  Note also, that constructing the CFG is not that slow
> (of course it depends on the edge count).
> 
the -O0 this is an aside.. to me -O0 ought not go through SSA, CFG or
anything, create trees, create RTl, generate code. it ought to be as
fast as possible. Other -O levels are for starting to do things to the
code.

> > We use the CFG in order to find
> > the right labels and such so we can amnipulate/optimize the EH stuff.
> 
> If you think this, you somehow miss basically _all_ optimizations
> implemented in GCC.  For the begin: we wouldn't even have halfway precise
> lifeness information of pseudos without a CFG (I know that this is no
> issue for SSA form).
Of course we couldn't do virtually any optimizations with a CFG to refer
to.
I was pointing out that we DONT currently need the CFG to generate
correct code for EH, so we currently dont have the CFG + IL situation
today as was indicated out in the previous mail. I was saying we make
use of the CFG to manipulate it. Dont take me out of context :-)

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]