On 6/19/19 7:38 AM, luoxhu wrote:
> Actually, the algorithm of function __gcov_one_value_profiler_body in
> libgcc/libgcov-profiler.c has functionality issue when profiling the testcase
> I provide.
It's designed to track most common value and uses only one slot for storage
place.
As mentioned I can easily prepare a patch that will store up to N values next
to each other. But first, Honza will have to make a general agreement about the
suggested IPA changes.
Thank you for understanding,
Martin
>
> 118 __gcov_one_value_profiler_body (gcov_type *counters, gcov_type value,
> 119 int use_atomic)
> 120 {
> 121 if (value == counters[1])
> 122 counters[2]++;
> 123 else if (counters[2] == 0)
> 124 {
> 125 counters[2] = 1;
> 126 counters[1] = value;
> 127 }
> 128 else
> 129 counters[2]--;
> 130
> 131 if (use_atomic)
> 132 __atomic_fetch_add (&counters[0], 1, __ATOMIC_RELAXED);
> 133 else
> 134 counters[0]++;
> 135 }
>
> function "one" is 1868707024, function "two" is 969338501. Loop running from
> 0->(350000000-1):
>
> value counters[0] counters[1] counters[2]
> 1868707024 1 1868707024 1
> 969338501 2 1868707024 0
> 1868707024 3 1868707024 1
> 969338501 4 1868707024 0
> 1868707024 5 1868707024 1
> ...
> 969338501 350000000 1868707024 0
>
> Finally, counters[] return value is [350000000, 1868707024, 0].
> In ipa-profile.c and value-prof.c, counters[0] is the statement that executed
> all, counters[2] is the indirect call that counters[1] executed which is 0
> here.
> This counters[2] shouldn't be 0 in fact, which means prob is 0(It was
> expected to be 50%, right?). This prob will cause ipa-profile fail to create
> speculative edge and do indirect call later. I think this is the reason why
> topn was introduced by Rong Xu in 2014 (8ceaa1e) and reimplemented that in
> LLVM later. There was definitely a bug here before re-enable topn.
