This is the mail archive of the gcc-patches@gcc.gnu.org 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


On Thu, 2003-11-13 at 19:12, Zdenek Dvorak wrote:
> 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. 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
present...

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?  

Andrew


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