This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions
- From: Xinliang David Li <davidxl at google dot com>
- To: Nathan Sidwell <nathan at acm dot org>
- Cc: Teresa Johnson <tejohnson at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Rong Xu <xur at google dot com>
- Date: Tue, 30 Sep 2014 21:49:36 -0700
- Subject: Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions
- Authentication-results: sourceware.org; auth=none
- References: <CAAe5K+UWHKvyeo9o1t16KsAn54A8FObES-sXnXT5Vycj_mTv7g at mail dot gmail dot com> <541EC90C dot 6050405 at acm dot org> <CAAkRFZKTNVDpKAEPo4LVnLBGRhHj7CgKtP_7EZ_6WcqZi9Xx2Q at mail dot gmail dot com> <541FDF9B dot 6020605 at acm dot org> <CAAe5K+VdiZJkHVLWgGjEQuDSrbnjSm0v6QvTCB_n4P3JcVRDaA at mail dot gmail dot com> <542B82DE dot 1000009 at acm dot org>
On Tue, Sep 30, 2014 at 9:28 PM, Nathan Sidwell <nathan@acm.org> wrote:
> On 09/22/14 08:04, Teresa Johnson wrote:
>
>
>> The approach we now take for LIPO builds is to propagate the counts
>
> LIPO?
>
See https://gcc.gnu.org/wiki/LightweightIpo It is a feature in google
GCC branches.
David
>> 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.)
>
>
> I'm presuming then that all modules of relevance are compiled with coverage
> information? Propagating counters from one module to another still seems
> wrong. It'll make it look like the function's executed more times than it
> really is (per copy). Plus in the general case one can't rely on the copies
> being identical implementations -- COMDAT only requires they be functionally
> equivalent.
>
>
>> 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.
>
>
> Um, I don't understand why you're doing this then? If gcov is ignoring the
> copies, what is the purpose?
>
> nathan