This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
- From: law at redhat dot com
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc-patches <gcc-patches at gcc dot gnu dot org>, jh at suse dot cz
- Date: Fri, 14 Nov 2003 13:35:24 -0700
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
- Reply-to: law at redhat dot com
In message <1068840451.2358.262.camel@p4>, Andrew MacLeod writes:
>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 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.
Based on my experience with our nested IL, I would tend to strongly
disagree. While it may seem like we could use the CFG and the old
containers to do this, I don't think it would have worked.
This was made painfully clear to me with the problems created when we
started threading jumps -- it tends to leave us with highly unstructured
code. Or imagine the problems with BIND_EXPRs -- to make this scheme work
we would have had to had more magic for BIND_EXPRs, or we would have needed
to treat them as starting/ending basic blocks.
The lowering of the IL was a good thing, regardless of whether or not
Zdenek had other long term goals.