[Bug tree-optimization/108355] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[Bug tree-optimization/108355] New: Dead Code Elimination Regression at -O2 (trunk vs. 12.2.0)

[yann at ywg dot ch]

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

            Bug ID: 108355
           Summary: Dead Code Elimination Regression at -O2 (trunk vs.
                    12.2.0)
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 54230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54230&action=edit
presented code as file

cat case.c #551
int a;
int *b = &a;
int **c = &b;
int d;
void bar25_(void);
void foo(void);
int main() {
  int e[][1] = {0, 0, 0, 0, 0, 1};
  for (;;) {
    bar25_();
    if (e[5][a])
      break;
    e[a][0] = 0;
    foo();
  }
  *c = &d;
}
`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O2 -S -o /dev/stdout
case.c`
--------- OUTPUT ---------
main:
.LFB0:
        .cfi_startproc
        subq    $40, %rsp
        .cfi_def_cfa_offset 48
        movl    $1, 20(%rsp)
        jmp     .L3
        .p2align 4,,10
        .p2align 3
.L6:
        movl    $0, (%rsp,%rax,4)
        call    foo
.L3:
        call    bar25_
        movslq  a(%rip), %rax
        movl    20(%rsp,%rax,4), %edx
        testl   %edx, %edx
        je      .L6
        movq    c(%rip), %rax
        movq    $d, (%rax)
        xorl    %eax, %eax
        addq    $40, %rsp
        .cfi_def_cfa_offset 8
        ret
---------- END OUTPUT ---------


`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
--------- OUTPUT ---------
main:
.LFB0:
        .cfi_startproc
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        call    bar25_
        movq    c(%rip), %rax
        movq    $d, (%rax)
        xorl    %eax, %eax
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        ret
---------- END OUTPUT ---------


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9baee6181b4e427e0b5ba417e51424c15858dce7

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Dead Code Elimination       |[13 Regression] Dead Code
                   |Regression at -O2 (trunk    |Elimination Regression at
                   |vs. 12.2.0)                 |-O2 since
                   |                            |r13-2772-g9baee6181b4e42
   Target Milestone|---                         |13.0
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-01-10

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  We're doing

Value numbering stmt = _2 = e[5][a.0_1];
Skipping possible redundant definition e[5][0] = 1;
Setting value number of _2 to _2 (changed)

now, by skipping the def we're no longer then optimistically assuming
a.0_1 == 0 when formerly using the assignment-from-constant _3 trick.

That wasn't done by design - if we'd handle this optimistically by
design we'd have more canonical reference ops for e[5][a.0_1].

Not sure if worth fixing.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Basically get_ref_base_and_extent trusts TYPE_SIZE of the array operand of an
ARRAY_REF (it would also use range info on an SSA name index, but we'd expect
a singleton to be propagated there already).  In principle that would be
a general "folding" trick we can apply to more consistently handle this
situation across passes.  gimplification might be the "nicest" place to
handle this, OTOH inlining / CCP might turn VLAs into [1] as well.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:a42ed1d9181d21d5cb02f131f641c0cf375eca9d

commit r13-5988-ga42ed1d9181d21d5cb02f131f641c0cf375eca9d
Author: Andrew Pinski <apinski@marvell.com>
Date:   Tue Jan 31 05:03:21 2023 +0000

    Simplify "1 - bool_val" to "bool_val ^ 1"

    For bool values, it is easier to deal with
    xor 1 rather than having 1 - a. This is because
    we are more likely to simplify the xor further in many
    cases.

    This is a special case for (MASK - b) where MASK
    is a powerof2 - 1 and b <= MASK but only for bool
    ranges ([0,1]) as that is the main case where the
    difference comes into play.

    Note this is enabled for gimple folding only
    as the ranges are only know while doing gimple
    folding and cfun is not always set when fold is called.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no
    regressions.

    gcc/ChangeLog:

            PR tree-optimization/108355
            PR tree-optimization/96921
            * match.pd: Add pattern for "1 - bool_val".

    gcc/testsuite/ChangeLog:

            PR tree-optimization/108355
            PR tree-optimization/96921
            * gcc.dg/tree-ssa/bool-minus-1.c: New test.
            * gcc.dg/tree-ssa/bool-minus-2.c: New test.
            * gcc.dg/tree-ssa/pr108354-1.c: New test.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #3)
> The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:
Sorry I forgot to fix the commit message for the corrected bug #.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[law at gcc dot gnu.org]

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

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/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:938a419182f8c43bd1212ffb98f8aa6077cf8326

commit r14-8929-g938a419182f8c43bd1212ffb98f8aa6077cf8326
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Feb 9 10:16:38 2024 +0100

    tree-optimization/113831 - wrong VN with structurally identical ref

    When we use get_ref_base_and_extent during VN and that ends up using
    global ranges to restrict the range of a ref we have to take care
    of not using the same expression in the hashtable as for a ref that
    could not use that global range.  The following attempts to ensure
    this by applying similar logic as get_ref_base_and_extent to
    copy_reference_ops_from_ref so they behave consistent.

            PR tree-optimization/113831
            PR tree-optimization/108355
            * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): When
            we see variable array indices and get_ref_base_and_extent
            can resolve those to constants fix up the ops to constants
            as well.
            (ao_ref_init_from_vn_reference): Use 'off' member for
            ARRAY_REF and ARRAY_RANGE_REF instead of recomputing it.
            (valueize_refs_1): Also fixup 'off' of ARRAY_RANGE_REF.

            * gcc.dg/torture/pr113831.c: New testcase.
            * gcc.dg/tree-ssa/ssa-fre-104.c: Likewise.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:5c01ede02a1f9ba1a58ab8d96a73e46e0484d820

commit r14-9216-g5c01ede02a1f9ba1a58ab8d96a73e46e0484d820
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Feb 28 13:45:57 2024 +0100

    tree-optimization/113831 - revert original fix

    This reverts the original fix for PR113831 which is better fixed by
    the PR114121 fix.  I've XFAILed instead of removing the PR108355
    testcase again.

            PR tree-optimization/113831
            PR tree-optimization/108355
            * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Revert
            PR113831 fix.

            * gcc.dg/tree-ssa/ssa-fre-104.c: XFAIL.

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |xfail
            Summary|[13 Regression] Dead Code   |[13/14 Regression] Dead
                   |Elimination Regression at   |Code Elimination Regression
                   |-O2 since                   |at -O2 since
                   |r13-2772-g9baee6181b4e42    |r13-2772-g9baee6181b4e42
      Known to work|14.0                        |

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu.org

--- Comment #10 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.

Any obvious target-specific reason for this to XPASS on cris-elf, m68k-linux
and pru-elf?

(per recent gcc-testresults posts)

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #10)
> (In reply to Richard Biener from comment #9)
> > gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.
> 
> Any obvious target-specific reason for this to XPASS on cris-elf, m68k-linux
> and pru-elf?
> 
> (per recent gcc-testresults posts)

Most likely because
int e[][1] = {0, 0, 0, 0, 0, 1};

Is done as a copy from a const static decl vs done via stores to e[i][0].

Maybe do s/5/2/ and change the number of elements down to 3 for the array and
you will hit the issue again on those targets.

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Hans-Peter Nilsson from comment #10)
> > (In reply to Richard Biener from comment #9)
> > > gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.
> > 
> > Any obvious target-specific reason for this to XPASS on cris-elf, m68k-linux
> > and pru-elf?
> > 
> > (per recent gcc-testresults posts)
> 
> Most likely because
> int e[][1] = {0, 0, 0, 0, 0, 1};
> 
> Is done as a copy from a const static decl vs done via stores to e[i][0].
> 
> Maybe do s/5/2/ and change the number of elements down to 3 for the array
> and you will hit the issue again on those targets.

Huh, most likely, but I don't see how that would help ... that should
make it _fail_ to optimize this ...

So checking cris-elf I see

  <bb 2> :
  e[0][0] = 0;
  e[1][0] = 0;
  e[2][0] = 0;
  e[3][0] = 0;
  e[4][0] = 0;
  e[5][0] = 1;

  <bb 3> :
  bar25_ ();
  a.0_1 = a;
  _2 = e[5][a.0_1];
  if (_2 != 0)
    goto <bb 5>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 4> :
  a.1_3 = a;
  e[a.1_3][0] = 0;
  foo ();
  goto <bb 3>; [INV]

before FRE, the same IL as on x86_64.  A FRE dump diff reveals

 Setting value number of a.0_1 to a.0_1 (changed)
 Making available beyond BB3 a.0_1 for value a.0_1
 Value numbering stmt = _2 = e[5][a.0_1];
-Skipping possible redundant definition e[5][0] = 1;
-Setting value number of _2 to _2 (changed)
-Using extra use virtual operand .MEM_5
-Making available beyond BB3 _2 for value _2
+Setting value number of _2 to 1 (changed)

that's exactly the reason for the regression - we're now trying to skip
the definition on x86_64.  And we can do so there because of the alignment
of 'e' which on cris seems to be less than the size of 'int' (int is
aligned to 1 byte but its size is still 4 bytes).

So

int a;
int *b = &a;
int **c = &b;
int d;
void bar25_(void);
void foo(void);
int main() {
  int __attribute__((aligned(sizeof(int)))) e[][1] = {0, 0, 0, 0, 0, 1};
  for (;;) {
    bar25_();
    /* We should optimistically treat a == 0 because of the bounds of
       the object.  */
    if (e[5][a])
      break;
    e[a][0] = 0;
    foo();
  }
  *c = &d;
}

also fails on cris.  Let me update the testcase.

[Bug tree-optimization/108355] [13/14 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:0bd04d9ae2d5447fd11fa43db20371140e955eff

commit r14-9382-g0bd04d9ae2d5447fd11fa43db20371140e955eff
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Mar 8 08:26:15 2024 +0100

    testsuite/108355 - make gcc.dg/tree-ssa/ssa-fre-104.c properly XFAIL

    The testcase only XFAILs on targets where int has an alignment
    of sizeof(int).  Align the respective array this way to make it
    XFAIL consistenlty.

            PR testsuite/108355
            * gcc.dg/tree-ssa/ssa-fre-104.c: Align e.

[Bug tree-optimization/108355] [13/14/15 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

[jakub at gcc dot gnu.org]

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

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

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

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