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

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

[theodort at inf dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108751

            Bug ID: 108751
           Summary: Removing dead code results in worse optimization at
                    -Os
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

I found this case where slight changes in the program that, in theory, should
not affect the output (or affect it trivially) cause the compiler to generate
worse code: 

static int a = 0;
static int b = 1;
int main() {
  char c = 0;
  for (;;) {
    if (c)
      break;
    for (; a; a++) { // a is 0, this loop is dead
      if (b) // this is always true
        continue;
      else
        return 2; // this program will never return 2
    }
    c = 10;
  }
  return 3;
}

compiled with gcc-trunk -Os: 

main:
.L2:
        movl    a(%rip), %eax
        testl   %eax, %eax
        je      .L6
        incl    %eax
        movl    %eax, a(%rip)
        jmp     .L2
.L6:
        movl    $3, %eax
        ret

Clearly, the compiler has figured out that "return 2;" will never be executed.
But if I remove it from the source:

static int a = 0;
static int b = 1;
int main() {
  char c = 0;
  for (;;) {
    if (c)
      break;
    for (; a; a++) {
      if (b)
        continue;
      //else
      // return 2;
    }
    c = 10;
  }
  return 3;
}

and compile with gcc-trunk -Os again:

main:
        movl    a(%rip), %eax
        xorl    %edx, %edx
.L2:
        testl   %eax, %eax
        jne     .L4
        testb   %dl, %dl
        je      .L7
        xorl    %eax, %eax
        movl    %eax, a(%rip)
        jmp     .L7
.L4:
        incl    %eax
        movb    $1, %dl
        jmp     .L2
.L7:
        movl    $3, %eax
        ret

the generated code is worse. 

The same thing happens if the return value is changed:

static int a = 0;
static int b = 1;
int main() {
  char c = 0;
  for (;;) {
    if (c)
      break;
    for (; a; a++) {
      if (b)
        continue;
      else
        return 2;
    }
    c = 10;
  }
  return 1; // changed from return 3
}

gcc-trunk -Os: 

main:
        movl    a(%rip), %eax
        xorl    %edx, %edx
.L2:
        testl   %eax, %eax
        jne     .L4
        testb   %dl, %dl
        je      .L7
        xorl    %eax, %eax
        movl    %eax, a(%rip)
        jmp     .L7
.L4:
        incl    %eax
        movb    $1, %dl
        jmp     .L2
.L7:
        movl    $1, %eax
        ret

and if we constant propagate b:

static int a = 0;
int main() {
  char c = 0;
  for (;;) {
    if (c)
      break;
    for (; a; a++) {
      if (1) // this was if (b) before
        continue;
      else
        return 2;
    }
    c = 10;
  }
  return 1;
}

gcc-trunk -Os:

main:
        movl    a(%rip), %eax
        xorl    %edx, %edx
.L2:
        testl   %eax, %eax
        jne     .L12
        testb   %dl, %dl
        je      .L7
        xorl    %eax, %eax
        movl    %eax, a(%rip)
        jmp     .L7
.L12:
        incl    %eax
        movb    $1, %dl
        jmp     .L2
.L7:
        movl    $1, %eax
        ret

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

[theodort at inf dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108751

--- Comment #1 from Theodoros Theodoridis <theodort at inf dot ethz.ch> ---
I am not sure if this qualifies as a "bug"/missed optimization but I'd be
interested in understanding why these changes cause such a difference. Thanks!

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

[jakub at gcc dot 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.