This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>,jh at suse dot cz
- Date: Fri, 14 Nov 2003 01:37:18 +0100
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
- References: <20031114001222.GA21863@atrey.karlin.mff.cuni.cz> <1068769823.9262.37.camel@p4>
> > 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
> > simpler.
> > 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.
when you have cfg, gotos are obviously redundant. The only reason for
having them would be if they made something simpler, but they do not;
they in fact complicate every cfg manipulation.
> understand there are benefits, but there are also negatives. Thats a big
> enough switch that we're almost handling 2 ILs in my books.
Could you be more specific about the negatives? I fail to see any.
> 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?
Yes, gotos are added back before expansion.