[Bug tree-optimization/110503] New: [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[Bug tree-optimization/110503] New: [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[theodort at inf dot ethz.ch]

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

            Bug ID: 110503
           Summary: [13/14 Regression] Dead Code Elimination Regression at
                    -O3 since  r13-322-g7f04b0d786e
           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/h3G76EEW5

Given the following code:

void foo(void);
static int f = 10, g, h;
static int *i = &g, *j = &f, *k = &h;
static char(a)(int b) {
    if (!(((b) >= 1) && ((b) <= 3))) {
        __builtin_unreachable();
    }
    return 0;
}
static char(c)(char d, char e) { return d % e; }
static void l() {
    char m, n;
    unsigned o;
    int *p = &g;
    o = -19;
    for (; o > 22; o = o + 8) {
        int *q = &g;
        g = 30;
        unsigned char d = 60, e = o;
        m = d / e;
        if ((0 || *q) & m == 0)
            ;
        else {
            foo();
            n = c(0 != p, *p);
            a(n);
            *q = 0;
        }
    }
    *i = a(3);
    *k = 0 != *j;
}
int main() {
    l();
    a(h);
}

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

main:
        pushq   %rbx
        movl    $-19, %ebx
        jmp     .L5
        .p2align 4,,10
        .p2align 3
.L8:
        call    foo
        addl    $8, %ebx
.L5:
        movl    $30, g(%rip)
        cmpb    $60, %bl
        jbe     .L8
        addl    $8, %ebx
        cmpl    $5, %ebx
        jne     .L5
        movl    f(%rip), %edx
        xorl    %eax, %eax
        popq    %rbx
        movl    $0, g(%rip)
        testl   %edx, %edx
        setne   %al
        movl    %eax, h(%rip)
        xorl    %eax, %eax
        ret

gcc-12.3.0 -O3 eliminates the call to foo:

main:
        movl    f(%rip), %edx
        xorl    %eax, %eax
        movl    $0, g(%rip)
        testl   %edx, %edx
        setne   %al
        movl    %eax, h(%rip)
        xorl    %eax, %eax
        ret

Bisects to r13-322-g7f04b0d786e

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[pinskia at gcc dot gnu.org]

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

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

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

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I noticed there is a missing optimization here (during VRP1):
  _29 = _11 == 0;
  _30 = (unsigned int) _29;
  _14 = -_30;
  if (_14 > 2)

That is just:
  if (_14 != 0)
or:
  if (_29 != 0)
or rather:
  if (_11 == 0)


Oh the difference between GCC 12 and GCC 13 is that completely unroll does not
happen.

GCC 13:
size: 13-6, last_iteration: 13-6
  Loop size: 13
  Estimated size after unrolling: 14
Not unrolling loop 1: contains call and code would grow.
Not peeling: upper bound is known so can unroll completely

GCC 12:
size: 13-6, last_iteration: 13-6
  Loop size: 13
  Estimated size after unrolling: 14
Making edge 11->7 impossible by redistributing probability to other edges.
Making edge 15->7 impossible by redistributing probability to other edges.
Making edge 6->8 impossible by redistributing probability to other edges.
/app/example.cpp:17:14: optimized: loop with 2 iterations completely unrolled
(header execution count 1073741833)
Exit condition of peeled iterations was eliminated.

Basically the comparatively size would increase too much ...

So this was just by accident I think.

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> I noticed there is a missing optimization here (during VRP1):
>   _29 = _11 == 0;
>   _30 = (unsigned int) _29;
>   _14 = -_30;
>   if (_14 > 2)
> 
> That is just:
>   if (_14 != 0)
> or:
>   if (_29 != 0)
> or rather:
>   if (_11 == 0)

I wonder if the above will decrease the "size" estimates enough to optimize
this again ...

Oh and had:
  # RANGE [irange] int [-128, 127]
  _10 = (intD.6) _9;
  # RANGE [irange] int [0, 1] NONZERO 0x1
  _11 = 1 % _10;

I wonder if we could optimize `1 % b` into just `b != 1` (since 1 % 0 is
undefined) which will further reduce things here.

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> 
> Oh and had:
>   # RANGE [irange] int [-128, 127]
>   _10 = (intD.6) _9;
>   # RANGE [irange] int [0, 1] NONZERO 0x1
>   _11 = 1 % _10;
> 
> I wonder if we could optimize `1 % b` into just `b != 1` (since 1 % 0 is
> undefined) which will further reduce things here.

That does not change the size of the loop though and we are still left with:
  size:   1 _10 = _9 == 1;
  size:   0 _11 = (unsigned int) _10;
  size:   1 _12 = -_11;
  size:   2 if (_12 > 2)

But at least now we just need to optimize the above to just `if (_9 == 1)`

Something like:
(simplify
 (gt (negative zero_one_value@0) INTEGER_CST@1)
 (if (wi::to_wide (@1) >= 1 && TYPE_UNSIGNED (TREE_TYPE (@1)))
  (ne @0 { build_zero_cst (TREE_TYPE (@1)); } )
  (if (wi::to_wide (@1) >= 0 && !TYPE_UNSIGNED (TREE_TYPE (@1)))
   (eq @0 { build_zero_cst (TREE_TYPE (@1)); } )
  )
 )
)

But I get the feeling this should be done in VRP instead of match ...

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

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

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=108360

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> I noticed there is a missing optimization here (during VRP1):
>   _29 = _11 == 0;
>   _30 = (unsigned int) _29;
>   _14 = -_30;
>   if (_14 > 2)
> 
> That is just:
>   if (_14 != 0)
> or:
>   if (_29 != 0)
> or rather:
>   if (_11 == 0)


That shows up similarly in PR 108360.

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
   Last reconfirmed|2023-06-30 00:00:00         |2023-8-25

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This will be fixed with my test_for_singularity patch.

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[law at gcc dot gnu.org]

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

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

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

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law <law at gcc dot gnu.org> ---
As you note, this feels like a failure to recognize that only one value can
actually satisfy the condition.

[Bug tree-optimization/110503] [13/14/15 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.