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] offline gcda profile processing tool

Hi, Honza,

Please find the new patch in the attachment. This patch integrated
your earlier suggestions. The noticeable changes are:
(1) build specialized object for libgcov-driver.c and libgcov-merge.c
and link into gcov-tool, rather including the source file.
(2) split some gcov counter definition code to gcov-counter.def to
avoid code duplication.
(3) use a macro for gcov_read_counter(), so gcov-tool can use existing
code in libgcov-merge.c with minimal change.

This patch does not address the suggestion of creating a new directory
for libgcov. I agree with you that's a much better
and cleaner structure we should go for. We can do that in follow-up patches.

I tested this patch with boostrap and profiledbootstrap. Other tests
are on-going.



On Wed, Apr 16, 2014 at 8:34 PM, Jan Hubicka <> wrote:
>> GCOT_TOOL needs to use this function to read the string in gcda file
>> to memory to construct gcov_info objects.
>> As you noticed, gcov runtime does not need this interface. But
>> gcov-tool links with gcov runtime and it also uses the function.
>> We could make it available in gcov_runtime, but that will slightly
>> increase the memory footprint.
> Yep, it is not really pretty. I wrote bellow some plan how things may be
> structured in more convenient way.  Any work in that direction would be welcome.
>> The planned new functions for trunk version is: (1) overlap score b/w
>> two profiles (2) better dumping (top hot objects/function/counters)
>> and statistics.
>> Once this basic version is in, we can start to add the new functionality.
> Sounds good. I assume the autoFDO does not go via gcov tool but rather uses
> custom reader of profile data at GCC side?
> I wonder, are there any recent overview papers/slides/text of design of AutoFDO
> and other features to be merged?
> I remember the talk from GCC Summit and I did read some of pre-LTO LIPO
> sources & papers, but it would be nice to have somethin up to date.
>> libgcov-util.o is built in gcc/ directory, rather in libgcc.
>> It's directly linked to gcov-tool.
>> So libgcov-util.o is built for HOST, not TARGET.
>> With makefile changes, we can built HOST version of libgcov-driver.o
>> and libgcov-merge.o.
>> I also need to make some static functions/variables public.
> I suppose that can go with IN_GCOV_TOOL ifdef.
> So we currently have basic gcov io handling in gcc/gcov-io.c that is borrowed
> by libgcc/libgcov* code.  We also will get libgcov-util.c in libgcc directory
> that is actually borrowed by by gcc/gcov-tool.c code.
> We now have one runtime using STDIO for streaming and kernel has custom version
> that goes via /proc interface (last time I looked).  We added some abstraction
> into libgcov-interface that is the part that relies on STDIO, partly via gcov-io.c
> code and now we have in-memory handling code in libgcov-util.
> I guess it would make most sentse to put all the gcov code into a new directory
> (libgcov) and make it stand-alone library that can be configured
> 1) for stdio based runtime as we do not
> 2) for runtime missing the interface and relyin on user providing it
> 3) for use within gcov file manipulation tools with reorg of
> GCC/gcov/gcov-dump/gcov-tool to all use the same low-level interfaces.
> In a longer term, I would like to make FDO profiling intstrumentation to happen
> at linktime. For that I need to make the instrumentation code (minimal spaning
> tree & friends) to work w/o cgraph that would ideally be done in a shared
> implementation
>> > Won't this get wrong answer when counters[0] is not the same?
>> > I would expected the merging code to compare the counters first. Similarly for delta counter.
>> These *_op functions are for scaling only. So there is only one
>> profile involved (thus there is no comparison).
>> The merge handles are in libgcov-merge.c which have the code to handle
>> mismatched profile targets.
> I see, OK then.
>> >
>> > Adding correct rounding may actually make difference for Martin's startup time work.
>> Do you mean to use something like in RDIV macro?
> Yes.
> Honza

Attachment: gcov_tool_patch_v3.txt
Description: Text document

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