[gcov] Simplify file interface

Jan Hubicka jh@suse.cz
Mon Apr 7 16:52:00 GMT 2003

> Jan Hubicka wrote:
> >Thinking about it a more, I think it is mistake to update it in two
> >passes.  The interface has been originally designed to allow updating at
> >local basis and we probably should maintain it given the cost in
> >threaded environment.  This needs just one relaxation:
> >
> >struct gcov_summary
> >{
> >  unsigned checksum;	  /* checksum of program */
> >  unsigned runs;	  /* number of program runs */
> >  unsigned arcs;	  /* number of instrumented arcs */
> >  gcov_type arc_sum;      /* sum of all arc counters */
> >  gcov_type arc_max_one;  /* max counter on any one run */
> >  gcov_type arc_max_sum;  /* maximum arc_sum */
> >^^^^
> >This one is not posible to maintain.  Instead we have only
> >arc_sum_max.  While this is definitly nice thing to know, it is not
> >critical and it is not used at all currently...  What do you think
> >about dropping this field and merging the summaries while updating the
> >file?
> >
> >  gcov_type arc_sum_max;  /* sum of max_one */
> I've been thinking that we don't use all these different counts anyway,
> we should only maintain the ones that are needed. Do we want the
> counts for a program (as opposed to an object file)? If we do, then
> a multi-phase scheme must be used.

In the addition to my patch, we can compute arc_max_sum correctly
without locking the whole program profile.  We can simply use two
passes, first one to update counters and rest of gcov_symmary and unlock
the file.  In the second pass we will lock the file, read gcov_summary
and if the number of runs is equal to the one we do remember, we update
I beleive this is not worthwhile since we don't use the value,
but perhaps we can add a comment that it is doable in the case someone
will need it.


More information about the Gcc-patches mailing list