This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Removal of gotos from cfg based ir

In message <>, Zdenek Dvorak wri
 >> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]