[llvm-bugs] [Bug 42709] New: Extra stack load/store generated for a volatile {i16, i16} store

[via llvm-bugs]

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

            Bug ID: 42709
           Summary: Extra stack load/store generated for a volatile {i16,
                    i16} store
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: glider at google.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

For the following program:

$ cat tb.c
typedef struct { short v1, v2;} st_t;
void foo(st_t a) {
  volatile st_t b;
  b = a;
}

GCC generates a single store to a stack slot:

$ gcc tb.c -O2 -c
$ objdump -d tb.o
...
0000000000000000 <foo>:
   0: 89 7c 24 fc          mov    %edi,-0x4(%rsp)
   4: c3                    retq  

, whereas Clang uses an extra stack slot to store %rdi for no reason:

$ clang tb.c -O2 -c
$ objdump -d tb.o...
0000000000000000 <foo>:
   0: 89 7c 24 f8          mov    %edi,-0x8(%rsp)
   4: 8b 44 24 f8          mov    -0x8(%rsp),%eax
   8: 89 44 24 fc          mov    %eax,-0x4(%rsp)
   c: c3                    retq  



According to the generated IR Clang chose to use a volatile load for that extra
slot:

; Function Attrs: nounwind uwtable
define dso_local void @foo(i32 %a.coerce) local_unnamed_addr #0 {
entry:
  %a.sroa.0 = alloca i32, align 4
  %b.sroa.0 = alloca i32, align 4
  store i32 %a.coerce, i32* %a.sroa.0, align 4
  %b.sroa.0.0.b.0..sroa_cast = bitcast i32* %b.sroa.0 to i8* 
  call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull
%b.sroa.0.0.b.0..sroa_cast)
  %a.sroa.0.0.a.sroa.0.0.a.sroa.0.0.copyload = load volatile i32, i32*
%a.sroa.0, align 4
  store volatile i32 %a.sroa.0.0.a.sroa.0.0.a.sroa.0.0.copyload, i32*
%b.sroa.0, align 4
  call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull
%b.sroa.0.0.b.0..sroa_cast)
  ret void
}

- maybe that prevented DSE from removing the dead store.

-- 
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/20190722/aca09c9e/attachment.html>