Logging data structure field accesses

[Robert Bowdidge]

Much thanks to Mike Capp for making the tables more readable.  Next 
time, I'll do the tables by hand.

> Here's two examples of the produced data.  Each represents the fields
> of declarations accessed when compiling a program that only includes
> the <Carbon/Carbon.h> header file (which brings in about 100K lines of
> header files.)  The first web page shows the results when  compiled
> with gcc, the second with g++.  (I'd done these measurements to
> understand why the C compiler only took 1 second to compile the
> headers, but the C++ compiler took two seconds.)  The count of accesses
> to the uid field indicates the number of declarations of each type, as
> the field is only accessed during creation of the declaration node.

BTW, I found the field access information most useful for creating 
smaller versions of the declaration data structure.  The information 
was less useful when trying to identify the differences between the 
compilers.  Just because the number of accesses to a particular field 
was high didn't imply that accessing that field was inefficient.  
However, looking at where the access patterns were different did 
highlight what code was expensive.

The biggest differences between the two compilers was in how the name 
field was accessed for function, type, and field declarations -- the 
name field gets accessed hundreds of thousands of times in the C++ 
compiler compared with tens of thousands of times in the C compiler.  
Most of the unusual field accesses were in functions called from 
finish_struct_1; profiling and instrumentation showed that about half 
of the time difference between the C and C++ compiler -- (.35 - .45 
seconds) -- was in this code.  I'd first thought that the compiler was 
doing too many separate passes over all the elements of each structure, 
but profiling showed that most of the time (.16 - .25 secs) was spent 
creating the implicit member functions needed for each struct.  The 
headers define 1200 structures, all intended to be used as C structures 
rather than classes.  For each, three function declarations 
(constructor, copy constructor, and assignment operator) get defined.  
Work in grokdeclarator and below is responsible for the majority of the 
time.

There are checks in grokdeclarator that are probably irrelevant for the 
implicit functions, or that could be done by examination of the 
class/structure rather than each function. For example, a non-trivial 
amount of time (about 8% of the cost of finish_struct_1) was being 
spent in no_linkage_check deciding whether any of the implicit 
functions referenced anonymous types that couldn't be exported.  
grokfield also looks at names trying to decide if any of the implicit 
function names are "_vptr", and thus will conflict with the virtual 
function table's field name.

I'm not sure we'd want to have separate paths for creating regular 
declarations and those for the implicit functions, but it was 
interesting to see where the time's going.

Robert