On Mon, Sep 22, 2014 at 1:36 AM, Nathan Sidwell <nat...@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. 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.
I don't think the above mechanism helps the problem my patches are trying to solve. Unless we are in whole-program mode, which we don't use, the only profiles available at profile-use time are those for the given module (and any other modules in the same module group in LIPO mode). If the COMDAT copy selected by the linker in the profile-gen binary is in a different module, we would see all-zero counts when compiling modules containing the other copies. I had submitted some patches to trunk awhile back in the 4.9 time frame to help deal with this by using estimated frequencies for zero-count COMDAT copies, and applying scaled counts when we inline them, but it is an imperfect solution. The approach we now take for LIPO builds is to propagate the counts 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.) > 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? 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. My patch does not do anything special for these routines when they are read into the profile-use build, because we do want the propagated counts during optimization. Possibly in whole-program mode they should be cleared on read just as in gcov-tool, or they could be flagged in some way for downstream phases, but it is not a compilation mode we are using so I have not experimented. Thanks, Teresa > > nathan -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
