[Bug c++/99078] New: Optimizer moves struct initialization into loop

[Bug c++/99078] New: Optimizer moves struct initialization into loop

[magiblot at hotmail dot com]

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

            Bug ID: 99078
           Summary: Optimizer moves struct initialization into loop
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: magiblot at hotmail dot com
  Target Milestone: ---

Consider the following piece of code (https://godbolt.org/z/WhTcbd):

> struct S
> {
>     char c[24];
> };
> 
> void copy(S *dest, unsigned count)
> {
>     S s {};
>     for (int i = 0; i < 7; ++i)
>         s.c[i] = i;
>     for (int i = 8; i < 15; ++i)
>         s.c[i] = i;
>     for (int i = 16; i < 23; ++i)
>         s.c[i] = i;
>     while (count--)
>         *dest++ = s;
> }

The generated assembly with -O2 looks like this:

> copy(S*, unsigned int):
>         mov     QWORD PTR [rsp-24], 0
>         pxor    xmm0, xmm0
>         movups  XMMWORD PTR [rsp-40], xmm0
>         test    esi, esi
>         je      .L1
>         mov     esi, esi
>         lea     rax, [rsi+rsi*2]
>         lea     rdx, [rdi+rax*8]
> .L3:
>         mov     eax, 1541
>         mov     ecx, 3340
>         mov     esi, 5396
>         mov     DWORD PTR [rsp-39], 67305985
>         mov     WORD PTR [rsp-35], ax
>         add     rdi, 24
>         mov     DWORD PTR [rsp-32], 185207048
>         mov     WORD PTR [rsp-28], cx
>         mov     BYTE PTR [rsp-26], 14
>         movdqu  xmm1, XMMWORD PTR [rsp-40]
>         mov     DWORD PTR [rsp-24], 319951120
>         mov     WORD PTR [rsp-20], si
>         mov     BYTE PTR [rsp-18], 22
>         mov     rax, QWORD PTR [rsp-24]
>         movups  XMMWORD PTR [rdi-24], xmm1
>         mov     QWORD PTR [rdi-8], rax
>         cmp     rdi, rdx
>         jne     .L3
> .L1:
>         ret

It can be seen that the struct initialization has been moved into the loop,
which is a severe pessimization.

The issue cannot be reproduced if the struct is initialized this way:

> S s;
> memset(&s, 0, sizeof(s));

But the following still reproduces the issue:

> S s {};
> memset(&s, 0, sizeof(s));

Replacing the assignment inside the loop with memcpy does not affect the
result.

According to Godbolt, the generated assembly has not changed since GCC 7.2. GCC
7.1 does not use vector registers but still initializes the struct inside the
loop. GCC 6.4 and earlier do not use vector registers either but do initialize
the struct outside the loop, as expected.

EXPECTED RESULT

Ideally, the loop body would be optimized into something like this:

>         movdqu  xmm1, XMMWORD PTR [rsp-40]
>         mov     rax, QWORD PTR [rsp-24]
> .L3:
>         add     rdi, 24
>         movups  XMMWORD PTR [rdi-24], xmm1
>         mov     QWORD PTR [rdi-8], rax
>         cmp     rdi, rdx
>         jne     .L3
> .L1:
>         ret

Thank you.

[Bug tree-optimization/99078] [8/9/10/11 Regression] Optimizer moves struct initialization into loop

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-02-12
      Known to work|                            |6.5.0
            Summary|Optimizer moves struct      |[8/9/10/11 Regression]
                   |initialization into loop    |Optimizer moves struct
                   |                            |initialization into loop
     Ever confirmed|0                           |1
          Component|c++                         |tree-optimization
           Keywords|                            |missed-optimization
      Known to fail|                            |11.0, 7.5.0
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P2
                 CC|                            |jamborm at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |8.5

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  It is SRA that with total scalarization re-materializes 's' before
the aggregate use it cannot transform (*dest_106 = s).  Looks like quite
pointless in any case (removing one set of inits just to re-emit them for
the single remat case), maybe there's no costing involved at all?

There isn't really sth like a pass that hoists stores so undoing this
is really hard which means better avoid total scalarization of sth
where rematerialization in a bigger loop depth is required?


--- t.C.117t.cplxlower1 2021-02-12 09:17:00.278704232 +0100
+++ t.C.118t.sra        2021-02-12 09:17:00.278704232 +0100
...
@@ -10,26 +58,46 @@

   <bb 2> [local count: 118111600]:
   s = {};
-  s.c[1] = 1;
-  s.c[2] = 2;
-  s.c[3] = 3;
-  s.c[4] = 4;
-  s.c[5] = 5;
-  s.c[6] = 6;
-  s.c[8] = 8;
-  s.c[9] = 9;
-  s.c[10] = 10;
-  s.c[11] = 11;
-  s.c[12] = 12;
-  s.c[13] = 13;
-  s.c[14] = 14;
-  s.c[16] = 16;
-  s.c[17] = 17;
-  s.c[18] = 18;
-  s.c[19] = 19;
-  s.c[20] = 20;
-  s.c[21] = 21;
-  s.c[22] = 22;
+  s$c$1_12 = 0;
+  s$c$2_5 = 0;
+  s$c$3_4 = 0;
+  s$c$4_101 = 0;
+  s$c$5_100 = 0;
+  s$c$6_99 = 0;
+  s$c$8_116 = 0;
+  s$c$9_119 = 0;
+  s$c$10_121 = 0;
+  s$c$11_124 = 0;
+  s$c$12_126 = 0;
+  s$c$13_129 = 0;
+  s$c$14_131 = 0;
+  s$c$16_64 = 0;
+  s$c$17_66 = 0;
+  s$c$18_69 = 0;
+  s$c$19_71 = 0;
+  s$c$20_74 = 0;
+  s$c$21_76 = 0;
+  s$c$22_79 = 0;
+  s$c$1_81 = 1;
+  s$c$2_84 = 2;
+  s$c$3_86 = 3;
+  s$c$4_89 = 4;
+  s$c$5_91 = 5;
+  s$c$6_94 = 6;
+  s$c$8_96 = 8;
+  s$c$9_29 = 9;
+  s$c$10_31 = 10;
+  s$c$11_34 = 11;
+  s$c$12_36 = 12;
+  s$c$13_39 = 13;
+  s$c$14_41 = 14;
+  s$c$16_44 = 16;
+  s$c$17_46 = 17;
+  s$c$18_49 = 18;
+  s$c$19_51 = 19;
+  s$c$20_54 = 20;
+  s$c$21_56 = 21;
+  s$c$22_59 = 22;
   count_104 = count_20(D) + 4294967295;
   if (count_20(D) != 0)
     goto <bb 3>; [89.00%]
@@ -40,6 +108,26 @@
   # dest_106 = PHI <dest_19(D)(2), dest_25(3)>
   # count_114 = PHI <count_104(2), count_23(3)>
   dest_25 = dest_106 + 24;
+  s.c[1] = s$c$1_81;
+  s.c[2] = s$c$2_84;
+  s.c[3] = s$c$3_86;
+  s.c[4] = s$c$4_89;
+  s.c[5] = s$c$5_91;
+  s.c[6] = s$c$6_94;
+  s.c[8] = s$c$8_96;
+  s.c[9] = s$c$9_29;
+  s.c[10] = s$c$10_31;
+  s.c[11] = s$c$11_34;
+  s.c[12] = s$c$12_36;
+  s.c[13] = s$c$13_39;
+  s.c[14] = s$c$14_41;
+  s.c[16] = s$c$16_44;
+  s.c[17] = s$c$17_46;
+  s.c[18] = s$c$18_49;
+  s.c[19] = s$c$19_51;
+  s.c[20] = s$c$20_54;
+  s.c[21] = s$c$21_56;
+  s.c[22] = s$c$22_59;
   *dest_106 = s;
   count_23 = count_114 + 4294967295;
   if (count_114 != 0)

[Bug tree-optimization/99078] [9/10/11/12 Regression] Optimizer moves struct initialization into loop

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug tree-optimization/99078] [9/10/11/12 Regression] Optimizer moves struct initialization into loop

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug tree-optimization/99078] [10/11/12/13 Regression] Optimizer moves struct initialization into loop

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug tree-optimization/99078] [10/11/12/13 Regression] Optimizer moves struct initialization into loop

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug tree-optimization/99078] [11/12/13/14 Regression] Optimizer moves struct initialization into loop

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug tree-optimization/99078] [11/12/13/14 Regression] Optimizer moves struct initialization into loop

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57475&action=edit
testcase

Just making it easier to access the testcase.