https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698
Bug ID: 77698
Summary: Loop not considered hot after profiling
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: powerpc64*-unknown-linux-gnu
Target: powerpc64*-unknown-linux-gnu
Build: powerpc64*-unknown-linux-gnu
// gcc -O3 -o run -fno-tree-vectorize -funroll-loops --param max-unroll-times=4
-fno-inline run.c
// -fprofile-generate/-fprofile-use
volatile long int j = 0;
void foo(long int *a, long int *b, long int n)
{
long int i;
for (i = 0; i < n; i++)
a[j] = *b;
}
long int a, b;
int main()
{
a = 1; b = 2;
foo(&a, &b, 1000000);
return (a+b);
}
When I built the above testcase with profile info and unrolling I noticed the
loop was not getting aligned. The label is getting skipped in
final.c:compute_alignments() because optimize_bb_for_size_p() is returning
true. I poked a little further and saw that predict.c:maybe_hot_count_p() is
returning false here:
return (count >= get_hot_bb_threshold ());
because 'count'=250000 and get_hot_bb_threshold() returns 1000000. The bb count
is correct for unrolling the loop by 4. The value returned by
get_hot_bb_threshold() seems incorrect, shouldn't need to be the max count to
be considered hot (with unrolling it will never have that value).
