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 09/22/14 08:04, Teresa Johnson wrote:


The approach we now take for LIPO builds is to propagate the counts

LIPO?

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


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