[Bug tree-optimization/108751] Removing dead code results in worse generated target code at -Os

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.