This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, jh at suse dot cz
- Date: 13 Nov 2003 19:30:16 -0500
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
- References: <20031114001222.GA21863@atrey.karlin.mff.cuni.cz>
On Thu, 2003-11-13 at 19:12, Zdenek Dvorak wrote:
> with cfg, ordinary gotos (not computed, local) do not carry any useful
> information and their presence complicates things (e.g. having to handle
> several types of edges, having to create new basic blocks sometimes when
> redirecting edges, and also having to remove superfluous gotos).
> Additionaly they of course consume some memory. This patch removes them
> during the lifespan of the cfg, thus making all of these issues much
> The same fact is used to represent conditional expressions in more
> memory efficient fashion (the only useful information from COND_EXPR is
> the condition, the rest is represented by cfg). To keep the things
> consistent, I have also massaged SWITCH_EXPRs to work the same way; in
> fact, it turned out to be natural to represent both of these
> constructions by a single statement -- CF_EXPR; this made it possible to
> simplify some of the code that previously was done twice, once for
> COND_EXPRs and once for SWITCH_EXPRs.
Doesn't this mean that the IL no longer represents the program by
itself? This would require that the CFG be present in order to correctly
process the program. I'm not convinced that this is such a good thing. I
understand there are benefits, but there are also negatives. Thats a big
enough switch that we're almost handling 2 ILs in my books.
Did we discuss/decide at some point this is the direction we want to go
and I missed it? If not, then I think we better. I dont want 5 different
variations of the IL depedning on what data structures happen to be
I like having the IL independant, and the CFG built over it. Are the
benefits of doing it this way really worthwhile? If you want to save the
IL and allow a GENERIC inliner to use tree optimized code, arent we
going to have to convert this CFG-GIMPLE IL back into GENERIC by adding
the GOTOs and such back in?