This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, jh at suse dot cz
- Date: Fri, 14 Nov 2003 13:02:07 -0700
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
- Reply-to: law at redhat dot com
In message <20031114003718.GA27530@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
>Hello,
>
>> > 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.
Actually, I would claim the opposite -- it's the CFG that is redundant, not
the gotos. We derive the CFG from the gotos and EH characteristics of the
program.
Jeff