[llvm-bugs] [Bug 27522] New: Inefficient passing of byval parameters

[via llvm-bugs]

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

            Bug ID: 27522
           Summary: Inefficient passing of byval parameters
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider:

  target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
  target triple = "i686-pc-windows-msvc18.0.0"

  %struct.S = type { i32 }

  define void @f() {
  entry:
    %agg.tmp = alloca %struct.S
    %x = getelementptr inbounds %struct.S, %struct.S* %agg.tmp, i32 0, i32 0
    store i32 42, i32* %x
    call void @g(%struct.S* byval nonnull align 4 %agg.tmp) 
    ret void
  }

  declare void @g(%struct.S* byval align 4)


$ bin/llc /tmp/a.ll -o -

[..]
_f:                                     # @f
# BB#0:                                 # %entry
        subl    $8, %esp
        movl    $42, 4(%esp)
        movl    4(%esp), %eax
        movl    %eax, (%esp)
        calll   _g
        addl    $8, %esp
        retl

That's quite a round-about way to put 42 on the stack.


Another example:

  struct S {
    int x;
  };

  void g(S);

  void f(int x) {
    g({x});
  }

$ bin/clang++ -target i686-pc-win32 -O3 -S -o - /tmp/a.cc
[..]
# BB#0:                                 # %entry
        subl    $8, %esp
        movl    12(%esp), %eax
        movl    %eax, 4(%esp)
        movl    4(%esp), %eax
        movl    %eax, (%esp)
        calll   "?g@@YAXUS@@@Z"
        addl    $8, %esp
        retl

We could just jump to g() directly instead :-)

-- 
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/20160425/6db93319/attachment-0001.html>