Re: [PATCH] offline gcda profile processing tool

[Jan Hubicka <hubicka at ucw dot cz>]

> 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