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

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

[yann at ywg dot ch]

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

            Bug ID: 108351
           Summary: Dead Code Elimination Regression at -O3 (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 54226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54226&action=edit
case file

cat case.c #51
struct a {
  int b;
} b;
static short c = 7, d, e, a, k;
int g;
struct a h;
int i;
int j;
void foo();
static struct a f(int l, unsigned short m) {
  a = e;
  k = d = j < i;
  if (m)
    return h;
  foo();
  return b;
}
int main() {
  for (; g;)
    f(1, c);
  f(7, 7);
  f(9, 7);
}

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O3` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O3` can.

`gcc-cb93c5f8008b95743b741d6f1842f9be50c6985c (trunk) -O3 -S -o /dev/stdout
case.c`
--------- OUTPUT ---------
f.isra.0:
.LFB3:
        .cfi_startproc
        testw   %di, %di
        je      .L4
        ret
        .p2align 4,,10
        .p2align 3
.L4:
        xorl    %eax, %eax
        jmp     foo
        .cfi_endproc
.LFE3:
        .size   f.isra.0, .-f.isra.0
        .section        .text.startup,"ax",@progbits
        .p2align 4
        .globl  main
        .type   main, @function
main:
.LFB1:
        .cfi_startproc
        movl    g(%rip), %eax
        testl   %eax, %eax
        je      .L6
.L7:
        jmp     .L7
        .p2align 4,,10
        .p2align 3
.L6:
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        movl    $7, %edi
        call    f.isra.0
        movl    $7, %edi
        call    f.isra.0
        xorl    %eax, %eax
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        ret
---------- END OUTPUT ---------


`gcc-releases/gcc-12.2.0 -O3 -S -o /dev/stdout case.c`
--------- OUTPUT ---------
main:
.LFB1:
        .cfi_startproc
        movl    g(%rip), %eax
        testl   %eax, %eax
        je      .L4
.L5:
        jmp     .L5
        .p2align 4,,10
        .p2align 3
.L4:
        xorl    %eax, %eax
        ret
---------- END OUTPUT ---------


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

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.2.0)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
            Summary|Dead Code Elimination       |[13 Regression] Dead Code
                   |Regression at -O3 (trunk    |Elimination Regression at
                   |vs. 12.2.0)                 |-O3 (trunk vs. 12.2.0)

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[13 Regression] Dead Code   |[13 Regression] Dead Code
                   |Elimination Regression at   |Elimination Regression at
                   |-O3 (trunk vs. 12.2.0)      |-O3 since
                   |                            |r13-4240-gfeeb0d68f1c708
   Last reconfirmed|                            |2023-01-10
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |jamborm at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Thanks for the report. Please use the title as I've just modified and if
possible, CC people who are authors of such a revision.

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I noticed that with the C++ front-end early inline inlines f into main but with
the C front-end it does not ...

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[yinyuefengyi at gmail dot com]

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

Xionghu Luo (luoxhu at gcc dot gnu.org) <yinyuefengyi at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yinyuefengyi at gmail dot com

--- Comment #3 from Xionghu Luo (luoxhu at gcc dot gnu.org) <yinyuefengyi at gmail dot com> ---
(In reply to Andrew Pinski from comment #2)
> I noticed that with the C++ front-end early inline inlines f into main but
> with the C front-end it does not ...

C++ generates different call instructions with C front-end:

<   D.3747 = f (7, 7);
<   D.3748 = f (9, 7);
---
>   f (7, 7);
>   f (9, 7);


then an extra return_cost cost is added to C++ front-end:

<   D.3747 = f (7, 7);
<               freq:1.00 size:  4 time: 13
<   D.3748 = f (9, 7);
<               freq:1.00 size:  4 time: 13
---
>   f (7, 7);
>               freq:1.00 size:  3 time: 12
>   f (9, 7);
>               freq:1.00 size:  3 time: 12


early inline pass inlines the two calls with C front-end but fails to inline
them with C++ front-end due to "growth 8 exceeds --param early-inlining-insns 
divided by number of calls". 

gcc/ipa-inline.cc:747    growth * (n + 1) > early_inlining_insns

gcc/opts.cc:687    { OPT_LEVELS_3_PLUS, OPT__param_early_inlining_insns_, NULL,
14 },


Tried revert the commit r13-4240-gfeeb0d68f1c708, the two calls still exits,
need also revert the commit r13-4686-g095a13eda2caf6.
(r13-4686 mentioned IPA-SRA detects whether parameters could be removed,
obviously it doesn't work well now if constants are not propagated before
IPA-SRA, it seems that the IPA-SRA only remove locally_unused parameters but
'm' is not locally used and the constants from caller are not visible in
IPA-SRA?)

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[yinyuefengyi at gmail dot com]

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

--- Comment #4 from Xionghu Luo (luoxhu at gcc dot gnu.org) <yinyuefengyi at gmail dot com> ---

> early inline pass inlines the two calls with C front-end but fails to inline
> them with C++ front-end due to "growth 8 exceeds --param
> early-inlining-insns  divided by number of calls". 
> 

Swap C and C++ here...

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
If you rename main to something else, like bar, and so the calls to f
outside of the loop are not considered cold, you get the GCC 12
behavior.  Is this reduced from a real-world problem?

Because on the testcase IPA-CP actually does what I would like it to
do, it iginores the first parameter because really IPA-SRA is better
placed to deal with it and then does not duplicate f for the cold
calls.

The fact that the GCC 12 heuristics first cloned for a constant in a
useless parameter in the loop and then, when removing it in the other
calls, it happened to find out that those two share the same constant
in the second parameter, which happened to make the function shorter,
is basically luck rather than design.

[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[law at gcc dot gnu.org]

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

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/108351] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/108351] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/108351] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

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

--- Comment #8 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #5)
> If you rename main to something else, like bar, and so the calls to f
> outside of the loop are not considered cold, you get the GCC 12
> behavior.  Is this reduced from a real-world problem?
> 

Yann?

[Bug tree-optimization/108351] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[yann at ywg dot ch]

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

--- Comment #9 from Yann Girsberger <yann at ywg dot ch> ---
> Is this reduced from a real-world problem?

No, it is reduced from a modified csmith/random program.

[Bug tree-optimization/108351] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #10 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Yann Girsberger from comment #9)
> > Is this reduced from a real-world problem?
> 
> No, it is reduced from a modified csmith/random program.

In that case let me close this, please reopen if you disagree with my assesment
in comment #5.  Thanks.