On Sun, Sep 21, 2014 at 5:48 AM, Nathan Sidwell <nat...@acm.org> wrote: > On 09/13/14 00:31, Teresa Johnson wrote: >> >> This patch addresses issues when running gcov-tool after performing >> COMDAT fixup during dyn-ipa. Functions that were previously all zero >> counts are marked, and the counts are discarded when being read in >> by gcov-tool before recalculating module groups and summary info. > > > I'm not sure I understand the design here. A few years ago I modified the > gcov data structures to cope with comdat, but failed to get the compiler > side changed to utilize that (without breaking firefox builds). You'll see > each function record (struct gcov_fn_info) has: > > const struct gcov_info *key; /* comdat key */ > > 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). > > 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. David > > nathan
