[Bug rtl-optimization/101708] New: Suboptimal codegen when clearing struct fields

[Bug rtl-optimization/101708] New: Suboptimal codegen when clearing struct fields

[cafxx+gcc.gnu.org at strayorange dot com]

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

            Bug ID: 101708
           Summary: Suboptimal codegen when clearing struct fields
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cafxx+gcc.gnu.org at strayorange dot com
  Target Milestone: ---

GCC trunk (as well as 11.2) currently seem to be performing suboptimal codegen
in reset2 and reset3, that in theory should yield the same (or very similar to
the) result of reset1:

struct example {
    unsigned a;
    unsigned char b;
    unsigned c:1;
    unsigned d:2;
    unsigned char f; 
    unsigned char g;
    unsigned e;
};

void reset1(struct example *e) {
    e->b = 0,
    e->d = 0,
    e->e = 0,
    e->f = 0,
    e->g = 0;
}

void reset2(struct example *e) {
    *e = (struct example) {
        .a = e->a,
        .c = e->c
    };
}

void reset3(struct example *e) {
    struct example tmp = {
        .a = e->a,
        .c = e->c
    };
    *e = tmp;
}

compiled with -O2 -Wall yields:

reset1:
        and     QWORD PTR [rdi+4], 63744
        ret
reset2:
        movzx   eax, BYTE PTR [rdi+5]
        mov     edx, DWORD PTR [rdi]
        mov     DWORD PTR [rdi+8], 0
        mov     QWORD PTR [rdi], 0
        and     eax, 1
        mov     DWORD PTR [rdi], edx
        mov     BYTE PTR [rdi+5], al
        ret
reset3:
        mov     QWORD PTR [rsp-8], 0
        mov     eax, DWORD PTR [rdi]
        mov     DWORD PTR [rsp-12], eax
        movzx   eax, BYTE PTR [rdi+5]
        and     eax, 1
        mov     BYTE PTR [rsp-7], al
        mov     rax, QWORD PTR [rsp-12]
        mov     QWORD PTR [rdi], rax
        mov     eax, DWORD PTR [rsp-4]
        mov     DWORD PTR [rdi+8], eax
        ret

Godbolt link: https://godbolt.org/z/asr57TWqq

Bug reported at the request of @gnutools:
https://twitter.com/gnutools/status/1421525698515251207

I tentatively selected rtl-optimization as the component, but I'm not familiar
at all with the internals of GCC: feel free to update as needed.

[Bug tree-optimization/101708] Suboptimal codegen when clearing struct fields

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug tree-optimization/101708] Suboptimal codegen when clearing struct fields

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-08-01
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, what is happening in the reset1 is the GIMPLE store merging pass is
able to do the merging while in the other cases it does not.

[Bug tree-optimization/101708] Suboptimal codegen when clearing struct fields

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
void reset2 (struct example * e)
{
  unsigned int _1;
  <unnamed-unsigned:1> _2;

  <bb 2> [local count: 1073741824]:
  _1 = e_4(D)->a;
  _2 = e_4(D)->c;
  *e_4(D) = {};
  e_4(D)->a = _1;
  e_4(D)->c = _2;
  return;

So yeah, store-merging could detect that ->a and ->c are preserved, not sure
how awkward that would be though.  It'll be "splitting" the zero-init {}
into pieces based on each "preserve previous value" store.  Or sth like that.