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

[Jan Hubicka <hubicka at ucw 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
> :-)
> 
> 1 - Where do you propose to emit the measurement code, and where do you
> plan to read it in? Presumably they have to be the same location...  I
> assume the measurement code is currently emitted in RTL land, probably
> early in the rtl cycle? Would we be doing that in the front end, or in
> SSA land? or just before SSA after the CFG is created?
> 
> 2 - Does profiling work on abnormal edges?  Ie, are throw edges
> annotated, or are they guessed/ignored/calculated when possible?

Also about the annotation.  The algorithm works by identifying minimal
spanning tree in the CFG.  It is enought to annotate only the
non-spanning tree edges as the rest of profile can be computed from the
rule that sum of counts of edges incomming to the block are matching
sum of counts of edges leaving the block  (the CFG is first extended via
fake edges to represent instructions that may terminate executiona and
such).
You can manage the minimal spanning tree to contain majority of abnormal
edges.

Honza