[llvm-bugs] [Bug 34173] New: clang allocates a stack variable for each function call that returns a struct

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Aug 12 12:42:06 PDT 2017


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

            Bug ID: 34173
           Summary: clang allocates a stack variable for each function
                    call that returns a struct
           Product: clang
           Version: 5.0
          Hardware: PC
                OS: OpenBSD
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mail at patrick-wildt.de
                CC: llvm-bugs at lists.llvm.org

Created attachment 18974
  --> https://bugs.llvm.org/attachment.cgi?id=18974&action=edit
test case

When compiling the Linux Radeon KMS Driver with -Wframe-larger-than=2047 the
radeon_combios.c file cannot be compiled.

As it turns out, if you do

  struct a b;
  b = test();
  b = test();
  b = test();
  b = test();

every call to test() will allocate space on the stack instead of reusing the
single allocation there should be. This can be seen in the LLVM IR as

  %6 = alloca %struct.a, align 4
  %7 = alloca %struct.a, align 4
  %8 = alloca %struct.a, align 4
  %9 = alloca %struct.a, align 4
  %10 = alloca %struct.a, align 4
  %11 = alloca %struct.a, align 4

...

  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %35, i8* %36, i64 68, i32 4, i1
false)
  call void @test(%struct.a* sret %9)
  %37 = bitcast %struct.a* %6 to i8*
  %38 = bitcast %struct.a* %9 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %37, i8* %38, i64 68, i32 4, i1
false)
  call void @test(%struct.a* sret %10)
  %39 = bitcast %struct.a* %6 to i8*
  %40 = bitcast %struct.a* %10 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %39, i8* %40, i64 68, i32 4, i1
false)
  call void @test(%struct.a* sret %11)

...

With clang 4.0.0 this issue does not exist.

-- 
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/20170812/ea3b3adf/attachment.html>


More information about the llvm-bugs mailing list