llvm.org GIT mirror llvm / ad60d3c
Change inalloca rules to make it only apply to the last parameter This makes things a lot easier, because we can now talk about the "argument allocation", which allocates all the memory for the call in one shot. The only functional change is to the verifier for a feature that hasn't shipped yet. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199434 91177308-0d34-0410-b5e6-96231b3b80d8 Reid Kleckner 5 years ago
6 changed file(s) with 125 addition(s) and 106 deletion(s). Raw diff Collapse all Expand all
66
77 .. Warning:: This feature is unstable and not fully implemented.
88
9 The :ref:`attr_inalloca` attribute is designed to allow taking the
10 address of an aggregate argument that is being passed by value through
11 memory. Primarily, this feature is required for compatibility with the
12 Microsoft C++ ABI. Under that ABI, class instances that are passed by
13 value are constructed directly into argument stack memory. Prior to the
14 addition of inalloca, calls in LLVM were indivisible instructions.
15 There was no way to perform intermediate work, such as object
16 construction, between the first stack adjustment and the final control
17 transfer. With inalloca, each argument is modelled as an alloca, which
18 can be stored to independently of the call. Unfortunately, this
19 complicated feature comes with a large set of restrictions designed to
20 bound the lifetime of the argument memory around the call, which are
21 explained in this document.
9 The :ref:`inalloca ` attribute is designed to allow
10 taking the address of an aggregate argument that is being passed by
11 value through memory. Primarily, this feature is required for
12 compatibility with the Microsoft C++ ABI. Under that ABI, class
13 instances that are passed by value are constructed directly into
14 argument stack memory. Prior to the addition of inalloca, calls in LLVM
15 were indivisible instructions. There was no way to perform intermediate
16 work, such as object construction, between the first stack adjustment
17 and the final control transfer. With inalloca, all arguments passed in
18 memory are modelled as a single alloca, which can be stored to prior to
19 the call. Unfortunately, this complicated feature comes with a large
20 set of restrictions designed to bound the lifetime of the argument
21 memory around the call.
2222
2323 For now, it is recommended that frontends and optimizers avoid producing
2424 this construct, primarily because it forces the use of a base pointer.
2929 Intended Usage
3030 ==============
3131
32 In the example below, ``f`` is attempting to pass a default-constructed
33 ``Foo`` object to ``g`` by value.
32 The example below is the intended LLVM IR lowering for some C++ code
33 that passes a default-constructed ``Foo`` object to ``g`` in the 32-bit
34 Microsoft C++ ABI.
35
36 .. code-block:: c++
37
38 // Foo is non-trivial.
39 struct Foo { int a, b; Foo(); ~Foo(); Foo(const &Foo); };
40 void g(Foo a, Foo b);
41 void f() {
42 f(1, Foo(), 3);
43 }
3444
3545 .. code-block:: llvm
3646
37 %Foo = type { i32, i32 }
47 %struct.Foo = type { i32, i32 }
48 %callframe.f = type { %struct.Foo, %struct.Foo }
3849 declare void @Foo_ctor(%Foo* %this)
39 declare void @g(%Foo* inalloca %arg)
50 declare void @Foo_dtor(%Foo* %this)
51 declare void @g(%Foo* inalloca %memargs)
4052
4153 define void @f() {
42 ...
54 entry:
55 %base = call i8* @llvm.stacksave()
56 %memargs = alloca %callframe.f
57 %b = getelementptr %callframe.f*, i32 0
58 %a = getelementptr %callframe.f*, i32 1
59 call void @Foo_ctor(%struct.Foo* %b)
4360
44 bb1:
45 %base = call i8* @llvm.stacksave()
46 %arg = alloca %Foo
47 invoke void @Foo_ctor(%Foo* %arg)
61 ; If a's ctor throws, we must destruct b.
62 invoke void @Foo_ctor(%struct.Foo* %arg1)
4863 to label %invoke.cont unwind %invoke.unwind
4964
5065 invoke.cont:
51 call void @g(%Foo* inalloca %arg)
66 store i32 1, i32* %arg0
67 call void @g(%callframe.f* inalloca %memargs)
5268 call void @llvm.stackrestore(i8* %base)
5369 ...
5470
5571 invoke.unwind:
72 call void @Foo_dtor(%struct.Foo* %b)
5673 call void @llvm.stackrestore(i8* %base)
5774 ...
5875 }
5976
60 The alloca in this example is dynamic, meaning it is not in the entry
61 block, and it can be executed more than once. Due to the restrictions
62 against allocas between an alloca used with inalloca and its associated
63 call site, all allocas used with inalloca are considered dynamic.
64
65 To avoid any stack leakage, the frontend saves the current stack pointer
66 with a call to :ref:`llvm.stacksave `. Then, it
67 allocates the argument stack space with alloca and calls the default
68 constructor. One important consideration is that the default
69 constructor could throw an exception, so the frontend has to create a
70 landing pad. At this point, if there were any other inalloca arguments,
71 the frontend would have to destruct them before restoring the stack
72 pointer. If the constructor does not unwind, ``g`` is called, and then
73 the stack is restored.
77 To avoid stack leaks, the frontend saves the current stack pointer with
78 a call to :ref:`llvm.stacksave `. Then, it allocates the
79 argument stack space with alloca and calls the default constructor. The
80 default constructor could throw an exception, so the frontend has to
81 create a landing pad. The frontend has to destroy the already
82 constructed argument ``b`` before restoring the stack pointer. If the
83 constructor does not unwind, ``g`` is called. In the Microsoft C++ ABI,
84 ``g`` will destroy its arguments, and then the stack is restored in
85 ``f``.
7486
7587 Design Considerations
7688 =====================
8092
8193 The biggest design consideration for this feature is object lifetime.
8294 We cannot model the arguments as static allocas in the entry block,
83 because all calls need to use the memory that is at the end of the call
84 frame to pass arguments. We cannot vend pointers to that memory at
85 function entry because after code generation they will alias. In the
86 current design, the rule against allocas between the inalloca alloca
87 values and the call site avoids this problem, but it creates a cleanup
88 problem. Cleanup and lifetime is handled explicitly with stack save and
89 restore calls. In the future, we may be able to avoid this by using
90 :ref:`llvm.lifetime.start ` and :ref:`llvm.lifetime.end
91 ` instead.
95 because all calls need to use the memory at the top of the stack to pass
96 arguments. We cannot vend pointers to that memory at function entry
97 because after code generation they will alias.
98
99 The rule against allocas between argument allocations and the call site
100 avoids this problem, but it creates a cleanup problem. Cleanup and
101 lifetime is handled explicitly with stack save and restore calls. In
102 the future, we may want to introduce a new construct such as ``freea``
103 or ``afree`` to make it clear that this stack adjusting cleanup is less
104 powerful than a full stack save and restore.
92105
93106 Nested Calls and Copy Elision
94107 -----------------------------
95108
96 The next consideration is the ability for the frontend to perform copy
97 elision in the face of nested calls. Consider the evaluation of
98 ``foo(foo(Bar()))``, where ``foo`` takes and returns a ``Bar`` object by
99 value and ``Bar`` has non-trivial constructors. In this case, we want
100 to be able to elide copies into ``foo``'s argument slots. That means we
101 need to have more than one set of argument frames active at the same
102 time. First, we need to allocate the frame for the outer call so we can
103 pass it in as the hidden struct return pointer to the middle call. Then
104 we do the same for the middle call, allocating a frame and passing its
105 address to ``Bar``'s default constructor. By wrapping the evaluation of
106 the inner ``foo`` with stack save and restore, we can have multiple
107 overlapping active call frames.
109 We also want to be able to support copy elision into these argument
110 slots. This means we have to support multiple live argument
111 allocations.
112
113 Consider the evaluation of:
114
115 .. code-block:: c++
116
117 // Foo is non-trivial.
118 struct Foo { int a; Foo(); Foo(const &Foo); ~Foo(); };
119 Foo bar(Foo b);
120 int main() {
121 bar(bar(Foo()));
122 }
123
124 In this case, we want to be able to elide copies into ``bar``'s argument
125 slots. That means we need to have more than one set of argument frames
126 active at the same time. First, we need to allocate the frame for the
127 outer call so we can pass it in as the hidden struct return pointer to
128 the middle call. Then we do the same for the middle call, allocating a
129 frame and passing its address to ``Foo``'s default constructor. By
130 wrapping the evaluation of the inner ``bar`` with stack save and
131 restore, we can have multiple overlapping active call frames.
108132
109133 Callee-cleanup Calling Conventions
110134 ----------------------------------
726726
727727 .. Warning:: This feature is unstable and not fully implemented.
728728
729 The ``inalloca`` argument attribute allows the caller to get the
730 address of an outgoing argument to a ``call`` or ``invoke`` before
731 it executes. It is similar to ``byval`` in that it is used to pass
732 arguments by value, but it guarantees that the argument will not be
733 copied.
734
735 To be :ref:`well formed `, the caller must pass in an
736 alloca value into an ``inalloca`` parameter, and an alloca may be
737 used as an ``inalloca`` argument at most once. The attribute can
738 only be applied to parameters that would be passed in memory and not
739 registers. The ``inalloca`` attribute cannot be used in conjunction
740 with other attributes that affect argument storage, like ``inreg``,
741 ``nest``, ``sret``, or ``byval``. The ``inalloca`` stack space is
742 considered to be clobbered by any call that uses it, so any
729 The ``inalloca`` argument attribute allows the caller to take the
730 address of all stack-allocated arguments to a ``call`` or ``invoke``
731 before it executes. It is similar to ``byval`` in that it is used
732 to pass arguments by value, but it guarantees that the argument will
733 not be copied.
734
735 To be :ref:`well formed `, an alloca may be used as an
736 ``inalloca`` argument at most once. The attribute can only be
737 applied to the last parameter, and it guarantees that they are
738 passed in memory. The ``inalloca`` attribute cannot be used in
739 conjunction with other attributes that affect argument storage, like
740 ``inreg``, ``nest``, ``sret``, or ``byval``. The ``inalloca`` stack
741 space is considered to be clobbered by any call that uses it, so any
743742 ``inalloca`` parameters cannot be marked ``readonly``.
744743
745 Allocas passed with ``inalloca`` to a call must be in the opposite
746 order of the parameter list, meaning that the rightmost argument
747 must be allocated first. If a call has inalloca arguments, no other
748 allocas can occur between the first alloca used by the call and the
749 call site, unless they are are cleared by calls to
750 :ref:`llvm.stackrestore `. Violating these rules
751 results in undefined behavior at runtime.
744 When the call site is reached, the argument allocation must have
745 been the most recent stack allocation that is still live, or the
746 results are undefined. It is possible to allocate additional stack
747 space after an argument allocation and before its call site, but it
748 must be cleared off with :ref:`llvm.stackrestore
749 `.
752750
753751 See :doc:`InAlloca` for more information on how to use this
754752 attribute.
909909
910910 if (Attrs.hasAttribute(Idx, Attribute::StructRet))
911911 Assert1(Idx == 1, "Attribute sret is not on first parameter!", V);
912
913 if (Attrs.hasAttribute(Idx, Attribute::InAlloca)) {
914 Assert1(Idx == FT->getNumParams(),
915 "inalloca isn't on the last parameter!", V);
916 }
912917 }
913918
914919 if (!Attrs.hasAttributes(AttributeSet::FunctionIndex))
15401545 // Verify call attributes.
15411546 VerifyFunctionAttrs(FTy, Attrs, I);
15421547
1543 // Verify that values used for inalloca parameters are in fact allocas.
1544 for (unsigned i = 0, e = CS.arg_size(); i != e; ++i) {
1545 if (!Attrs.hasAttribute(1 + i, Attribute::InAlloca))
1546 continue;
1547 Value *Arg = CS.getArgument(i);
1548 Assert2(isa(Arg), "Inalloca argument is not an alloca!", I,
1549 Arg);
1550 }
1551
15521548 if (FTy->isVarArg()) {
15531549 // FIXME? is 'nest' even legal here?
15541550 bool SawNest = false;
15821578
15831579 Assert1(!Attrs.hasAttribute(Idx, Attribute::StructRet),
15841580 "Attribute 'sret' cannot be used for vararg call arguments!", I);
1581
1582 if (Attrs.hasAttribute(Idx, Attribute::InAlloca))
1583 Assert1(Idx == CS.arg_size(), "inalloca isn't on the last argument!",
1584 I);
15851585 }
15861586 }
15871587
18871887 Assert1(AI.getArraySize()->getType()->isIntegerTy(),
18881888 "Alloca array size must have integer type", &AI);
18891889
1890 // Verify that an alloca instruction is not used with inalloca more than once.
1891 unsigned InAllocaUses = 0;
1892 for (User::use_iterator UI = AI.use_begin(), UE = AI.use_end(); UI != UE;
1893 ++UI) {
1894 CallSite CS(*UI);
1895 if (!CS)
1896 continue;
1897 unsigned ArgNo = CS.getArgumentNo(UI);
1898 if (CS.isInAllocaArgument(ArgNo)) {
1899 InAllocaUses++;
1900 Assert1(InAllocaUses <= 1,
1901 "Allocas can be used at most once with inalloca!", &AI);
1902 }
1903 }
1904
19051890 visitInstruction(AI);
19061891 }
19071892
0 ; RUN: not llvm-as %s -o /dev/null 2>&1 | FileCheck %s
1
2 declare void @h(i32, ...)
3 define void @i() {
4 %args = alloca i32
5 call void (i32, ...)* @h(i32 1, i32* inalloca %args, i32 3)
6 ; CHECK: inalloca isn't on the last argument!
7 ret void
8 }
1616
1717 declare void @f(void ()* inalloca %p)
1818 ; CHECK: do not support unsized types
19
20 declare void @g(i32* inalloca %p, i32 %p2)
21 ; CHECK: inalloca isn't on the last parameter!
None ; RUN: not llvm-as %s -o /dev/null 2>&1 | FileCheck %s
0 ; This used to be invalid, but now it's valid. Ensure the verifier
1 ; doesn't reject it.
2 ; RUN: llvm-as %s -o /dev/null
13
24 declare void @doit(i64* inalloca %a)
35
68 %a = alloca [2 x i32]
79 %b = bitcast [2 x i32]* %a to i64*
810 call void @doit(i64* inalloca %b)
9 ; CHECK: Inalloca argument is not an alloca!
1011 ret void
1112 }
1213
1516 %a = alloca i64
1617 call void @doit(i64* inalloca %a)
1718 call void @doit(i64* inalloca %a)
18 ; CHECK: Allocas can be used at most once with inalloca!
1919 ret void
2020 }