Re: "Documentation by paper"

[Jan Hubicka <hubicka at ucw dot cz>]

>     Everybody with less than guru knowledge of gcc asks, why.  And why CSE
>     propagates addressof into memories.  And who takes care of it for
>     nonoptimizing compilation.  And whether it is even needed for
>     nonoptimizing compilation.  And the flow of thought goes on.
> 
> Indeed.  The ADDRESSOF addition was one that gave GCC a lot of
> trouble, precisely because of the issues you raise, that its semantics
> were very poorly defined.
> 
> I see that as cautionary that we need to do better in the future, not
> as something to emulate into the future!

I hope that addressof will be elliminated soon.  In fact I do have patch
for this for tree-SSA, but still we need to resolve on how to optimize
out the casts of stype *(const char *)&char_variable that occurs
commonly in gimplified C++ code (Richard Henderson has plans on fixing
C++ FE to avoid producing this, so hope this will be sorted out soon)
> 
>     Passes that are developed right now, especially as part of the
>     tree-ssa work (but also Jan and Zdenek's rtlopt work), work at a
>     different, more generic level, and require a different kind of culture
>     on the reader.
> 
> Perhaps, but we have to be very careful of setting too high a level of
> knowlege to know to be able to work on GCC.  Sure, if you're working on
> subtle parts of these algorithms, you need to understand them "cold", but
> an overview description is essential for those doing minor work in these
> files.

I would agree here that the notion of counts/frequencies/probabilites,
hottness/coldness of basic block and various types of edges is midly
confusing (the last one even to someone who knows what CFG/profile is).

I tried to use quite precise names that results in longer identifiers
(like maybe_hot_bb_p/probably_cold_bb_p) that indicate what kind of
approximation it is, but it is still not very obvous.

I wrote chaper to gccint.texi devoted to the CFG and profile and I think
it is quite shame that it never has been accepted.  Steven has updated
version.  This only show that it is quite dificult to judge where the
documentation shall go in the current scheme.

Honza
> 
> As I said, the Bison manual even defines the term "symbol".  That sort of
> approach seems the appropriate one to me.