[gcov] Simplify file interface

Nathan Sidwell nathan@codesourcery.com
Mon Apr 7 19:22:00 GMT 2003


Jan Hubicka wrote:

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

Do we really need to track per-program summaries at all? Especially
as with multi-use object files, it is ill-defined what the summary of
summaries would mean. I've just been talking with Jason, and we couldn't
see why the per-object summary would not suffice. Why wouldn't simply
knowing the max_one_run[1] and sum_max_this_run[2] for a single object file
be sufficient for determining hot-spots? If it is important to know
how much a particular object file's code is used in a program, could
that not be provided by some other mechanism?

[1] this would be max counter value over all counters and runs
[2] this would be the sum over all runs of the max counter value on a run

For identical runs num_runs * [1] == [2]

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org




More information about the Gcc-patches mailing list