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"


> > > 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

I thought of it more as an aid in debugging performance problems, as in,
checking the dumps without introducing new statistics counters; in which
case, having some description of what the counters mean and the metadata
from the .def file would be useful.

On the other hand, I agree that for the purpose that you suggest
avoiding .def is better.  Perhaps we could require that all the
statistics strings are #defined and documented (and of course you can
ignore this rule for the counters that you use for experimentation)?


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