This is the mail archive of the gcc-patches@gcc.gnu.org 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: [gcov] Simplify file interface


> 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

This is important to get idea about what are the hot spots.

> as with multi-use object files, it is ill-defined what the summary of

It is not big problem - it should be summary over all programs
containing given file.

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

Yes, these two are important for me.  I don't care much onwhether they
are per program or not, but I think once we do have this feature it is
not needed to drop it.

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


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