https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108751
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The code isn't smaller, which indeed for -Os is important, though many GIMPLE
decisions need to be done just from heuristics whether a particular
transformation typically results in smaller or larger code, because the sizes
can't be compared until much later, just estimated.
What happens in this testcase is that b is determined to be constant only
during IPA optimizations, ccp2 after IPA then propagates the value of 1 into b
users and before lim2 we have pretty much the same IL (if I rename ssa name
versions and temporary suffixes), the only difference of between one where b
has been discovered constant 1 after IPA and where it has been determined 1
earlier is in the counts and branch probabilities:
- <bb 2> [local count: 1018865821]:
+ <bb 2> [local count: 536870913]:
goto <bb 5>; [100.00%]
- <bb 3> [local count: 54876003]:
+ <bb 3> [local count: 536870911]:
return 3;
- <bb 4> [local count: 460874625]:
+ <bb 4> [local count: 264428955]:
_2 = a.2_3 + 1;
a = _2;
- <bb 5> [local count: 997745539]:
+ <bb 5> [local count: 801299868]:
a.2_3 = a;
if (a.2_3 != 0)
- goto <bb 4>; [94.50%]
+ goto <bb 4>; [33.00%]
else
- goto <bb 3>; [5.50%]
+ goto <bb 3>; [67.00%]
Later on, lim2 decides to perform invariant motion in the latter case and not
in the former based on the probabilities.
In the first assembly
movl %eax, a(%rip)
is done in an inner loop, while in the latter case it is done only after the
loop finishes.
