This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
> On Fri, 2003-11-14 at 16:17, Jan Hubicka wrote:
> > > In message <20031114070054.GD18752@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
> > > tes:
> > >
> > > The IL is all we need to represent a function -- we derive auxiliary
> > > data from that IL -- for example, we can derive a CFG from that IL.
> > >
> > > With your change the IL is no longer sufficient to represent the program.
> > > So for example, you either have to save the CFG for inlining or you have
> > > to run through the CFG and insert jumps before you save the IL for inlining.
> > I would ineed love to save CFG for inlining. We need be able to read
> > profile for whole program, do profile based inlining and update
> > profiling after the inlining operation.
> > I believe that this is best done if inliner works on CFG.
> > This is not easy change, but this is where I would like to get.
> Why do we have to save the CFG in order to make inlining CFG aware? just
> build it when you want it. I think inlining ough to be another
> compilation phase that works on GENERIC/GIMPLE, like tree-ssa, and you
> can stick it where-ever in the compilation phase you like. It takes
> GENERIC/GIMPLE in, and spits GENERIC/GIMPLE out.
Do you want to extend all tree nodes to contain profile information?
This is doable, but not too easy - for instance where you want to store
frequency of exception produced by a=b/c?
CFG is convenient place to store this information. I don't quite see
what makes IL having CFG to represent control flow less clean that IL
that use gotos/EH/switch nodes.
> ideally, anyway :-)