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: [RFC] libgcov.c re-factoring and offline profile-tool


>>
>>  #ifdef L_gcov_merge_ior
>>  /* The profile merging function that just adds the counters.  It is given
>> -   an array COUNTERS of N_COUNTERS old counters and it reads the same number
>> -   of counters from the gcov file.  */
>> +   an array COUNTERS of N_COUNTERS old counters.
>> +   When SRC==NULL, it reads the same number of counters from the gcov file.
>> +   Otherwise, it reads from SRC array.  */
>>  void
>> -__gcov_merge_ior (gcov_type *counters, unsigned n_counters)
>> +__gcov_merge_ior (gcov_type *counters, unsigned n_counters,
>> +                  gcov_type *src, unsigned w __attribute__ ((unused)))
>
> So the new in-memory variants are introduced for merging tool, while libgcc use gcov_read_counter
> interface?
> Perhaps we can actually just duplicate the functions to avoid runtime to do all the scalling
> and in_mem tests it won't need?


I thought about this one a little. How about making the interface
change conditionally, but still share the implementation?  The merge
function bodies mostly remain unchanged and there is no runtime
penalty for libgcov.  The new macros can be shared across most of the
mergers.

#ifdef IN_PREOFILE_TOOL
#define GCOV_MERGE_EXTRA_ARGS  gcov_type *src, unsigned w
#define GCOV_READ_COUNTER  *(src++) * w
#else
#define GCOV_MERGE_EXTRA_ARGS
#define GCOV_READ_COUNTER gcov_read_counter ()
#endif

__gcov_merge_add (gcov_type *counters, unsigned n_counters,
                                  GCOV_MERGE_EXTRA_ARGS)
{

 for (; n_counters; counters++, n_counters--)
  {
      *counters += GCOV_READ_COUNTER ;
   }

}

thanks,

David

>
> I would suggest going with libgcov.h changes and clenaups first, with interface changes next
> and the gcov-tool is probably quite obvious at the end?
> Do you think you can split the patch this way?
>
> Thanks and sorry for taking long to review. I should have more time again now.
> Honza


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