[Bug tree-optimization/110540] New: [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[Bug tree-optimization/110540] New: [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[theodort at inf dot ethz.ch]

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

            Bug ID: 110540
           Summary: [14 Regression] Dead Code Elimination Regression since
                    r14-1163-gd8b058d3ca4
           Product: gcc
           Version: 14.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: ---

https://godbolt.org/z/WP14EKx7M

Given the following code:

void foo(void);
static int a = 1;
static int *d = &a;
static int **f = &d;
static int ***g = &f;
static char(h)(char b, char c) { return b - c; }
static char(i)(int e) {
    if (!(((e) >= 1) && ((e) <= 254))) {
        __builtin_unreachable();
    }
    return 0;
}
int main() {
    char j = 0;
    for (; j != -9; j = h(j, 9)) {
        i(1);
        *d = a ^ 255;
        if (i(a) >= **f) **f = 0;
    }
    if (**g)
        ;
    else
        foo();
    ;
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
        movl    a(%rip), %eax
        movq    f(%rip), %rdx
        movq    d(%rip), %rcx
        xorb    $-1, %al
        movl    %eax, (%rcx)
        movq    (%rdx), %rax
        movl    (%rax), %ecx
        testl   %ecx, %ecx
        jle     .L8
.L4:
        xorl    %eax, %eax
        ret
        .p2align 4,,10
        .p2align 3
.L8:
        cmpq    $0, (%rdx)
        movl    $0, (%rax)
        jne     .L4
        pushq   %rax
        call    foo
        xorl    %eax, %eax
        popq    %rdx
        ret

gcc-13.1.0 -O2 eliminates the call to foo:

main:
        movl    a(%rip), %eax
        movq    d(%rip), %rdx
        xorb    $-1, %al
        movl    %eax, (%rdx)
        movq    f(%rip), %rax
        movq    (%rax), %rax
        movl    (%rax), %ecx
        testl   %ecx, %ecx
        jg      .L2
        xorl    %edx, %edx
        movl    %edx, (%rax)
.L2:
        xorl    %eax, %eax
        ret

Bisects to r14-1163-gd8b058d3ca4

[Bug tree-optimization/110540] [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
           Keywords|                            |missed-optimization

[Bug tree-optimization/110540] [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-07-06
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

After threadfull2 we have:
  # VUSE <.MEM_17>
  _6 = *f.3_5;
  # VUSE <.MEM_17>
  _7 = *_6;
  if (_7 <= 0)
    goto <bb 3>; [5.50%]
  else
    goto <bb 6>; [94.50%]

  <bb 3> [local count: 55807731]:
  # .MEM_19 = VDEF <.MEM_17>
  *_6 = 0;
  # VUSE <.MEM_19>
  _10 = *f.3_5;
  if (_10 != 0B)
    goto <bb 5>; [0.00%]
  else
    goto <bb 4>; [100.00%]


But there is nothing which will optimize the load of *f.3_5 to be _6 before
vrp2 (which is the next pass).

There seems to be some other issues earlier on which gets us to that IR that
late but I am not sure how ...

[Bug tree-optimization/110540] [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So what is happening is EVRP is able to figure out _35 in the below:
  # RANGE [irange] int [-8, 0]
  _12 = (intD.6) j_16;
  # RANGE [irange] unsigned char [0, 0][248, +INF]
  b.7_32 = (unsigned char) j_16;
  # RANGE [irange] unsigned char [239, 247]
  _34 = b.7_32 + 247;
  # RANGE [irange] char [-17, -9]
  _35 = (charD.7) _34;

Is -9 rather than a range.
And then everything goes down here from there. Including loop detection ...

[Bug tree-optimization/110540] [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[amacleod at redhat dot com]

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

--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
EVRP figures out the j value can only be 0 or -9 and removes a few stmts as a
result, and simplifies the PHI, producing

  <bb 7> [local count: 114863530]:
  # j_12 = PHI <0(2), -9(6)>

  <bb 8> [local count: 1073741824]:
  # j_11 = PHI <j_12(7), -9(12)>
  if (j_11 != -9)
    goto <bb 3>; [94.50%]
  else
    goto <bb 9>; [5.50%]

which when we get to cunolli , looks like a loop and it does nothing.

When EVRP doesn't reduce the range from [-9, 0], we are instead left with:
  <bb 8> :
  # j_16 = PHI <0(2), _35(7)>
  if (j_16 != -9)
    goto <bb 3>; [INV]
  else
    goto <bb 9>; [INV]

After DSE, we have:
<bb 6> :
  *_8 = 0;

  <bb 8> : 
  # j_16 = PHI <0(2), -9(6), -9(5)>
  if (j_16 != -9)
    goto <bb 3>; [INV]
  else
    goto <bb 9>; [INV]

and the  CDDCE comes along and that turns into:
<bb 6> :
  *_8 = 0;

  <bb 7> :
  # j_17 = PHI <0(2), -9(6)>

  <bb 8> :
  # j_16 = PHI <j_17(7), -9(5)>
  if (j_16 != -9)
    goto <bb 3>; [INV]
  else
    goto <bb 9>; [INV]

Which is what eventually causes our problem, and this ends up looking like
another loop to cunrolli, and it does no analysis of it other than to mark it
as a 3rd loop.   And we never actually get rid of this.

IN the original version, cunroll analysis the loop and turns it into something
useful, without the extra phi..

If we dont do ccdce, then the same transformation shows up after switchconv in
profile_estimate..

So IM guessing this is a CFG "cleanup".

So EVRP cleans up the code, but it appears that it confuses cunrolli into
thinking there is nothing to do?

[Bug tree-optimization/110540] [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |law at gcc dot gnu.org

[Bug tree-optimization/110540] [14/15 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |14.2

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.