This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

Sorry, Lightweight IPO (https://gcc.gnu.org/wiki/LightweightIpo),
implemented and used on google branches. We don't use LTO for
scalability reasons. With LIPO the decisions about how to group
modules for cross-module optimization are done at the end of the
profiling run, which is where I have implemented these COMDAT fixups.

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

That's already the case with the copy selected by the linker, which
contains counts from all out-of-line copies of the COMDAT. This just
enables other modules to have access to the same profile data for
their copy of the COMDAT when they are compiled. It is correct that if
you sum together all the counts across all copies of the COMDAT, it
would look hotter than it should. But in this case we essentially only
see one copy when compiling each module.


> Plus in the general case one can't rely on the copies
> being identical implementations -- COMDAT only requires they be functionally
> equivalent.

We only do the copying when the cfg and line checksums match, so they
are most likely identical.

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

The new gcov-tool is ignoring the copies, when it reads in the
profiles and redoes the LIPO call graph analysis (on the google
branch). But the compiler does not ignore the copied counts. So the
compiler sees non-zero counts for these COMDAT routines and can
optimize more effectively.

In any case, David pointed out that with your approach we wouldn't
need to do the copying that I have implemented here for LIPO.
Teresa

>
> nathan



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]