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


> > 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.

> 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.

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.


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