[GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions

Teresa Johnson tejohnson@google.com
Mon Sep 22 15:04:00 GMT 2014

On Mon, Sep 22, 2014 at 1:36 AM, Nathan Sidwell <nathan@acm.org> wrote:
> On 09/21/14 18:58, Xinliang David Li wrote:
>>> the intent is that that points to the gcov_info object of the object file
>>> containing the live version of the function.  I couldn't quite get this
>>> to
>>> work though -- it involves emitting a function's gcov_fn_info decl in the
>>> same comdat group as the function itself.
>> Another problem is that comdat functions may have different CFGs due
>> to different early inline decisions. Comdatting gcov counters can lead
>> to problems in profile use. Not comdatting profile counters have
>> another advantage -- it allows context sensitive profiling for comdat
>> function inline instances (IPA-inline).
> IIRC early inlining is done before the counters are created.  You're right
> later inlining may be a problem, and require a non-comdat set of cloned
> counters.   I can't recall exactly at what stage the counters are now
> inserted relative to inlining.  The CFG machinery had a number of
> significant changes while, and shortly after, I was working on this.
>>> You'll see the checking of gfi_ptr->key != gi_ptr in libgcov-driver.c.
>>> Are you making use of this machinery, or inventing new machinery?
>> Teresa's method is a different machinery -- it tries to propagate
>> profile data from the selected comdat copy + inline instance copies to
>> comdat copies with zero counts.
> It'd be preferrable to complete the mechanism I outline above, rather than
> have a competing mechanism.

I don't think the above mechanism helps the problem my patches are
trying to solve. Unless we are in whole-program mode, which we don't
use, the only profiles available at profile-use time are those for the
given module (and any other modules in the same module group in LIPO
mode). If the COMDAT copy selected by the linker in the profile-gen
binary is in a different module, we would see all-zero counts when
compiling modules containing the other copies. I had submitted some
patches to trunk awhile back in the 4.9 time frame to help deal with
this by using estimated frequencies for zero-count COMDAT copies, and
applying scaled counts when we inline them, but it is an imperfect

The approach we now take for LIPO builds is to propagate the counts
for the profiled copy of the COMDAT to other modules. (Additionally
the indirect call profiling we perform in LIPO mode would point to a
module that we didn't have access to, which is a related issue that
the COMDAT fixups we perform at the end of the LIPO profiling run are
trying to solve.)

> Also, this patch  is in effect lying because
> the data then makes it look like the unselected comdat instances are in fact
> being executed -- looking at the whole program it's going to be harder to
> understand whether the different inline instances are being executed
> multiple times, or are duplicate data.  Does the gcov user output indicate
> this subtlety in some way?

Correct in that it makes it look like these copies were executed. This
was causing some issues when we rewrote/merged profiles with
gcov-tool, which essentially operates in whole-program mode. To handle
this, this patch marks the modified (previously all-zero) copies in
the gcda file. So now gcov-tool can handle them appropriately (clear
them on read before doing any analysis), and gcov-dump will flag them.
My patch does not do anything special for these routines when they are
read into the profile-use build, because we do want the propagated
counts during optimization. Possibly in whole-program mode they should
be cleared on read just as in gcov-tool, or they could be flagged in
some way for downstream phases, but it is not a compilation mode we
are using so I have not experimented.


> nathan

Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413

More information about the Gcc-patches mailing list