Re: [tree-ssa, RFC] CFG transparent RTL expansion

[Jan Hubicka <jh at suse dot cz>]

> > On Thu, 2003-12-18 at 19:44, Jan Hubicka wrote:
> > > Hi,
> > > I am attaching patch implementing the quite much discussed idea of expanding
> > > RTL out of GIMPLE CFG transparently.  The patch do have some rough edges and
> > > can be decomposed to about 5 incremental steps so it is not intended for
> > > detailed review rather than a demonstration/proof of the concept in a hope that
> > > it will make decision easier (the patch however bootstraps and works well).
> > > 
> > > The problem I am trying to solve is question on how to preserve profile
> > > information out of SSA based passes.  It is clear that most effective consumers
> > > of profile include inlining, loop optimization, register allocation and basic
> > > block reordering so profile must be available in about whole compilation pass.
> > > Actually measuring profile in multiple stages of compilation is possible, but
> > > earlier optimizations invalidate later measured profile so it require user to
> > > do multiple train runs that is unfortunate so I think it is a must to have
> > > machinery to preserve profile as well as possible from before inlining up to
> > > final.
> > > 
> > > From the work on RTL, the experience shows that CFG is the most natural place
> > > to store information into and about only place where updating after control
> > > flow transformations is manageable (still not easy), the alternatives like
> > > remembering execution counts for each instructions or branch probabilities for
> > > conditional branches does not work well for nontrivial updates.
> > 
> > I need more details :-). 
> > 
> > This implements something which isnt actually used yet (ie, no
> > collection emitted/done). If I read it correctly, just a proof of
> > concept of a persistant CFG. So lets skip to how it would actually be
> > used. And excuse my lackof knowledge about how gcc collects profile info
> > :-)
> I already do have patches to produce profile estimates early (no profile
> feedback, but it is the same thing for updating)

Also note that updating current profiling code for trees is more or less
trivial issue.  I do plan to keep ability to profile RTL for
experimenting with reading the profile back later in the process to see
how much difference it makes.

Honza