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

[Xinliang David Li <davidxl at google dot com>]

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.

Yes, and that will be the cause of problem for coverage mismatch when
COMDATing profile counters -- due to difference in early inline
decisions, the counter array created may be different across modules.

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

After early inining and before ipa inline.  The early inline can lead
to the coverage mismatch, and the latter can lead to loss of profile
precision with the counter comdat.


David

>
>>> 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.  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?
>
> nathan