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