This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Statistics "infrastructure"

On Sun, 16 Mar 2008, Zdenek Dvorak wrote:

> Hi,
> > This is an attempt to provide (pass) statistics collection.  The
> > goal is to provide infrastructure to handle the current (pass specific)
> > statistics dumping that is done per function and per pass along the
> > regular tree/rtl dumps as well as to allow CU wide "fancy" analysis.
> > 
> > The most important aspect I think is simplicity to use it and especially
> > add new "counters".  Thus, we simply associate a counter with a string ID.
> > 
> > The patch is a rough implementation of the current features of
> > pass specific statistics plus a global "log" with statistics events.
> > In the end you can do any postprocessing / globbing / summing of
> > such global log.
> > 
> > A statistics event consists of a function (optional), a statement
> > (optional) and the counter ID.  I converted the counters from
> > tree-ssa-propagate.c as an example, instead of
> > 
> > 		prop_stats.num_copy_prop++;
> > 
> > you now write
> > 
> > 		statistics_add ("copy propagations");
> > 
> > (function and statement omitted, you might prefer #defines for strings
> > that you use multiple times).
> it would perhaps be better to use #defines with integer values?  Also,
> it would be more consistent to have statistics.def similar to
> timevar.def for this.  It would make creation of new counters a bit
> more difficult, but on the other hand, it would make it possible to
> classify the counters (by type of the counted operation/its
> expensiveness/...),

The difficultness to add new counters is exactly why I didn't go
down that route.  I expect this mainly used for experimentation
where it is IMHO inconvenient to go the .def route (also like
with timevar.def we probably just get false re-use of IDs).
We might auto-generate (part of) the ID from the instrumentation
point (FILE/LINE) as well... (thus get "copy prop at xyz.c:25")

The point is to have easy instrumentation this way and automatic
analysis, not some stable interface (IMHO).  For this reason
classifying the counters is engineering at the wrong point - you'd
do that at the analysis point and not hard-code this somewhere
(after all, just name it "lim expensive" ;)).


Richard Guenther <>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]