[llvm-bugs] [Bug 40456] New: missed optimization for struct initialization

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40456

            Bug ID: 40456
           Summary: missed optimization for struct initialization
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dvyukov at google.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

During structure initialization on stack/heap clang avoids touching
uninitialized fields and padding. Initialization of uninit fields and padding
is allowed and I think in lots of cases will lead to smaller/faster code. For
example consider:

Source:

struct A {
        int a = 0;
        char b;
        short c = 0;
        char d = 0;
        short e;
        short f;
        char g = 0;
};

struct B {
        int a = 0;
        char b = 0;
        short c = 0;
        char d = 0;
        short e = 0;
        short f = 0;
        char g = 0;
};

struct C {
        int a = 0;
        short b = 0;
        short c = 0;
        short d = 0;
        short e = 0;
        short f = 0;
        short g = 0;
};

A* newA() { return new A; }
B* newB() { return new B; }
C* newC() { return new C; }


Generated code with -O3:

0000000000000000 <_Z4newAv>:
   0:   50                      push   %rax
   1:   bf 10 00 00 00          mov    $0x10,%edi
   6:   e8 00 00 00 00          callq  b <_Z4newAv+0xb>
   b:   c7 00 00 00 00 00       movl   $0x0,(%rax)
  11:   66 c7 40 06 00 00       movw   $0x0,0x6(%rax)
  17:   c6 40 08 00             movb   $0x0,0x8(%rax)
  1b:   c6 40 0e 00             movb   $0x0,0xe(%rax)
  1f:   59                      pop    %rcx
  20:   c3                      retq   
  21:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  28:   00 00 00 
  2b:   0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

0000000000000030 <_Z4newBv>:
  30:   50                      push   %rax
  31:   bf 10 00 00 00          mov    $0x10,%edi
  36:   e8 00 00 00 00          callq  3b <_Z4newBv+0xb>
  3b:   c7 00 00 00 00 00       movl   $0x0,(%rax)
  41:   c6 40 04 00             movb   $0x0,0x4(%rax)
  45:   66 c7 40 06 00 00       movw   $0x0,0x6(%rax)
  4b:   c6 40 08 00             movb   $0x0,0x8(%rax)
  4f:   c7 40 0a 00 00 00 00    movl   $0x0,0xa(%rax)
  56:   c6 40 0e 00             movb   $0x0,0xe(%rax)
  5a:   59                      pop    %rcx
  5b:   c3                      retq   
  5c:   0f 1f 40 00             nopl   0x0(%rax)

0000000000000060 <_Z4newCv>:
  60:   50                      push   %rax
  61:   bf 10 00 00 00          mov    $0x10,%edi
  66:   e8 00 00 00 00          callq  6b <_Z4newCv+0xb>
  6b:   0f 57 c0                xorps  %xmm0,%xmm0
  6e:   0f 11 00                movups %xmm0,(%rax)
  71:   59                      pop    %rcx
  72:   c3                      retq   

Clang could emit 1 movups in all of these cases. That's 2 instructions/6 bytes
vs 6 instructions/31 bytes.

clang version 8.0.0 (trunk 350842)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190125/12a88229/attachment.html>