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

[Nathan Sidwell]

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