> Here is the patch updated to use the new parameter from r203830.
> Passed bootstrap and regression tests.
>
> 2013-10-18 Jan Hubicka <j...@suse.cz>
> Teresa Johnson <tejohn...@google.com>
>
> * predict.c (handle_missing_profiles): New function.
> (counts_to_freqs): Don't overwrite estimated frequencies
> when function has no profile counts.
> * predict.h (handle_missing_profiles): Declare.
> * tree-profile.c (tree_profiling): Invoke handle_missing_profiles.
>
> Index: predict.c
> ===================================================================
> --- predict.c (revision 203830)
> +++ predict.c (working copy)
> @@ -2758,6 +2758,40 @@ estimate_loops (void)
> BITMAP_FREE (tovisit);
> }
>
You need block comment. It should explain the problem of COMDATs and how they
are handled.
It is not an obvious thing.
> +void
> +handle_missing_profiles (void)
> +{
> + struct cgraph_node *node;
> + int unlikely_count_fraction = PARAM_VALUE (UNLIKELY_BB_COUNT_FRACTION);
extra line
> + /* See if 0 count function has non-0 count callers. In this case we
> + lost some profile. Drop its function profile to PROFILE_GUESSED. */
> + FOR_EACH_DEFINED_FUNCTION (node)
> + {
> + struct cgraph_edge *e;
> + gcov_type call_count = 0;
> + struct function *fn = DECL_STRUCT_FUNCTION (node->symbol.decl);
Extra line
> + if (node->count)
> + continue;
> + for (e = node->callers; e; e = e->next_caller)
> + call_count += e->count;
What about checking if the sum is way off even for non-0 counts.
I.e. for case where function was inlined to some calls but not to others? In
that case we may want to scale up the counts (with some resonable care for
capping)
Also I think the code really should propagate - i.e. have simple worklist and
look for functions that are COMDAT and are called by other COMDAT functions
where we decided to drop the profile. Having non-trivial chains of comdats is
common thing.
What about outputting user visible warning/error on the incosnsistency when
no COMDAT function is involved same way as we do for BB profile?
Honza
