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

[Jan Hubicka <jh at suse dot cz>]

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

Honza
> 
> ideally, anyway :-)
> 
> Andrew