https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120065
--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
while (n > 0 && a)
;
This is an odd loop which loops iterates 0 times or infinitely many times.
We do not pattern match that at profile-estimate time (since such code is kind
of useless) and we guess it iterates 8.09 times.
Befoe dom 2 we have:
a.0_17 = a;
if (a.0_17 != 0B)
goto <bb 9>; [94.50%]
else
goto <bb 5>; [5.50%]
<bb 9>:
<bb 4>:
a.0_1 = a;
if (a.0_1 != 0B)
goto <bb 11>; [94.50%]
else
goto <bb 5>; [5.50%]
<bb 11>
goto bb 4
<bb 5>:
... for loop
We do not yet see that the loop is infinite.
Dom optimizes it to:
if (n_9(D) > 0)
goto <bb 3>; [48.59%]
else
goto <bb 8>; [51.41%]
<bb 3>:
a.0_17 = a;
if (a.0_17 != 0B)
goto <bb 4>; [94.50%]
else
goto <bb 5>; [5.50%]
<bb 4>:
Here is "Invalid sum of incoming counts 1011616600 (estimated locally, freq
8.8071), should be 958878295 (estimated locally, freq 8.3480)"
a.0_1 = a.0_17;
goto <bb 4>; [100.00%]
<bb 5>
Here is "Invalid sum of incoming counts 3069425 (estimated locally, freq
0.0267), should be 102228543 (estimated locally, freq 0.8900)"
j = 0;
j.4_16 = 0;
if (n_9(D) > 0)
goto <bb 6>; [100.00%]
else
goto <bb 7>; [0.00%]
Now BB 4 is a self loop which by itself can not have right profile (frequency
would have to be infinity and thus it gets capped to something) and bb 5 is now
header of the for loop. Before we discovered that while loop is infinite, we
expected it to finish and go to next loop and that is why the profile is too
high after removing this path.
It is kind of pathological case, but if infinite was discovered in early
optimizations things would be smoother overall. Function body would be smaller,
profile would not be mis-guessed. We could detect that if forced progression is
on, the program is valid only if the whole loop does not iterate)
