https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103680
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |acoplan at gcc dot gnu.org
--- Comment #13 from Alex Coplan <acoplan at gcc dot gnu.org> ---
I came across the following testcase (reduced from
gcc/testsuite/g++.dg/torture/pr116902.C) which shows profile mismatches
starting in jump threading:
$ cat t.cc
unsigned a;
long i_d;
void i(char c[][4]) {
for (char e; e; e += ~0)
for (bool h = 0; h < bool(i_d); h = 1)
a = c[2][1] - c[2][2];
}
I see:
$ ./xgcc -B . -c t.cc -O2 -S -o /dev/null
-fdump-tree-threadfull1-blocks-details=- | grep -B 1 "Invalid sum"
;; basic block 3, loop depth 1, count 955630224 (estimated locally, freq
65.4628), maybe hot
;; Invalid sum of incoming counts 114571471 (estimated locally, freq 7.8484),
should be 955630224 (estimated locally, freq 65.4628)
--
;; basic block 5, loop depth 1, count 118111600 (estimated locally, freq
8.0909), maybe hot
;; Invalid sum of incoming counts 959170353 (estimated locally, freq
65.7053), should be 118111600 (estimated locally, freq 8.0909)
where the profile was at least consistent in the previous pass:
$ ./xgcc -B . -c t.cc -O2 -S -o /dev/null
-fdump-tree-mergephi2-blocks-details=- | grep -B 1 "Invalid sum"
looking at the jump threading dump I see:
> Jump threading proved that the probability of edge 4->5 was originally
> estimated too small. (it is 11.0% (guessed) should be 89.0% (guessed))
which suggests that jump threading is just exposing a problem in the profile
that was introduced earlier, but didn't manifest as an inconsistent profile.
