Re: [tree-ssa] cfg.texi needs reviewing by a native speaker (Was: Re: "Documentation by paper")

[Jan Hubicka <hubicka at ucw dot cz>]

> In message <200402042105.28601.stevenb@suse.de>, Steven Bosscher writes:
>  >On Wednesday 04 February 2004 20:09, Robert Dewar wrote:
>  >> Joe Buck wrote:
>  >> > OK, the *best* would be written by that almost non-existent programmer
>  >> > who combines a love of writing clear English prose with the extraordinary
>  >> > discipline required to do it first and keep it current.  But since this
>  >> > species is almost non-existent, you need to read my phrase "best
>  >> > documentation" for "best documentation achievable in practice".
>  >>
>  >> You are FAR too pessimistic, I know lots of programmers who meet
>  >> these criteria.
>  >
>  >I most certainly don't qualify for Joe's description.  I'm sure one
>  >of you does, and since part of this discussion was about documenting
>  >what a basic block is, I kindly ask you, as native speakers who care
>  >about good documentation, to review this new chapter for the manual.
>  >
>  >It's based on Jan Hubicka's old cfg.texi, which he&others wrote after
>  >doing a lot of work on the CFG representation in GCC.  That document
>  >is almost three years old now, but it was never reviewed (not even by
>  >the people in this thread who say they care about documentation).  I
>  >don't claim it's perfect -- on the contrary.  But does it look like
>  >an acceptable start?
>  >
>  >Thanks,
>  >
>  >Gr.
>  >Steven
>  >
>  >doc/
>  >	* cfg.texi: New chapter for the internals manual.  Briefly describes
>  >	the data structures used to represent the control flow graph, and
>  >	the issues and API to modify and maintain the CFG.
> Approved.  
> 
> Funny -- I was looking for some of this just the other day (frequency stuff).
> 
> Now what we need is better documentation of things like the algorithms we're
> using to do prediction & frequency computation/propagation. :-)

It is one of topics I am considering for gccsummit (other one I am
considering is cgraph code that will proably win this time as I still do
plan to extend the profiling for inlining and would like to cover it
once complette). 

However the algorithm itself match almost perfectly the Wu & Larus
approach described in the linked paper.  It is natural enough - you are
simply walking the inner loops as acyclic regions and compute the
frequency of loopback edge.  Then you get to outer loop and multiply the
frequency of header block of inner loop accordingly.

The interfaces to predictors are different tought, but I hope these are
documented well enough.

Honza
> 
> 
> Jeff