This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
- From: Michael Matz <matz at suse dot de>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,Jeff Law <law at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>,<jh at suse dot cz>
- Date: Fri, 14 Nov 2003 20:14:12 +0100 (CET)
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
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
(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.
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.
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.
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).
> 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).