maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Verifier/inalloca2.ll

40 lines
721 B
LLVM
Raw Normal View History

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. llvm-svn: 199434
2014-01-17 06:59:24 +08:00
; This used to be invalid, but now it's valid. Ensure the verifier
; doesn't reject it.
; RUN: llvm-as %s -o /dev/null
Begin adding docs and IR-level support for the inalloca attribute The inalloca attribute is designed to support passing C++ objects by value in the Microsoft C++ ABI. It behaves the same as byval, except that it always implies that the argument is in memory and that the bytes are never copied. This attribute allows the caller to take the address of an outgoing argument's memory and execute arbitrary code to store into it. This patch adds basic IR support, docs, and verification. It does not attempt to implement any lowering or fix any possibly broken transforms. When this patch lands, a complete description of this feature should appear at http://llvm.org/docs/InAlloca.html . Differential Revision: http://llvm-reviews.chandlerc.com/D2173 llvm-svn: 197645
2013-12-19 10:14:12 +08:00
declare void @doit(i64* inalloca %a)
define void @a() {
entry:
IR: Change inalloca's grammar a bit The grammar for LLVM IR is not well specified in any document but seems to obey the following rules: - Attributes which have parenthesized arguments are never preceded by commas. This form of attribute is the only one which ever has optional arguments. However, not all of these attributes support optional arguments: 'thread_local' supports an optional argument but 'addrspace' does not. Interestingly, 'addrspace' is documented as being a "qualifier". What constitutes a qualifier? I cannot find a definition. - Some attributes use a space between the keyword and the value. Examples of this form are 'align' and 'section'. These are always preceded by a comma. - Otherwise, the attribute has no argument. These attributes do not have a preceding comma. Sometimes an attribute goes before the instruction, between the instruction and it's type, or after it's type. 'atomicrmw' has 'volatile' between the instruction and the type while 'call' has 'tail' preceding the instruction. With all this in mind, it seems most consistent for 'inalloca' on an 'inalloca' instruction to occur before between the instruction and the type. Unlike the current formulation, there would be no preceding comma. The combination 'alloca inalloca' doesn't look particularly appetizing, perhaps a better spelling of 'inalloca' is down the road. llvm-svn: 203376
2014-03-09 14:41:58 +08:00
%a = alloca inalloca [2 x i32]
Begin adding docs and IR-level support for the inalloca attribute The inalloca attribute is designed to support passing C++ objects by value in the Microsoft C++ ABI. It behaves the same as byval, except that it always implies that the argument is in memory and that the bytes are never copied. This attribute allows the caller to take the address of an outgoing argument's memory and execute arbitrary code to store into it. This patch adds basic IR support, docs, and verification. It does not attempt to implement any lowering or fix any possibly broken transforms. When this patch lands, a complete description of this feature should appear at http://llvm.org/docs/InAlloca.html . Differential Revision: http://llvm-reviews.chandlerc.com/D2173 llvm-svn: 197645
2013-12-19 10:14:12 +08:00
%b = bitcast [2 x i32]* %a to i64*
call void @doit(i64* inalloca %b)
ret void
}
define void @b() {
entry:
IR: Change inalloca's grammar a bit The grammar for LLVM IR is not well specified in any document but seems to obey the following rules: - Attributes which have parenthesized arguments are never preceded by commas. This form of attribute is the only one which ever has optional arguments. However, not all of these attributes support optional arguments: 'thread_local' supports an optional argument but 'addrspace' does not. Interestingly, 'addrspace' is documented as being a "qualifier". What constitutes a qualifier? I cannot find a definition. - Some attributes use a space between the keyword and the value. Examples of this form are 'align' and 'section'. These are always preceded by a comma. - Otherwise, the attribute has no argument. These attributes do not have a preceding comma. Sometimes an attribute goes before the instruction, between the instruction and it's type, or after it's type. 'atomicrmw' has 'volatile' between the instruction and the type while 'call' has 'tail' preceding the instruction. With all this in mind, it seems most consistent for 'inalloca' on an 'inalloca' instruction to occur before between the instruction and the type. Unlike the current formulation, there would be no preceding comma. The combination 'alloca inalloca' doesn't look particularly appetizing, perhaps a better spelling of 'inalloca' is down the road. llvm-svn: 203376
2014-03-09 14:41:58 +08:00
%a = alloca inalloca i64
Begin adding docs and IR-level support for the inalloca attribute The inalloca attribute is designed to support passing C++ objects by value in the Microsoft C++ ABI. It behaves the same as byval, except that it always implies that the argument is in memory and that the bytes are never copied. This attribute allows the caller to take the address of an outgoing argument's memory and execute arbitrary code to store into it. This patch adds basic IR support, docs, and verification. It does not attempt to implement any lowering or fix any possibly broken transforms. When this patch lands, a complete description of this feature should appear at http://llvm.org/docs/InAlloca.html . Differential Revision: http://llvm-reviews.chandlerc.com/D2173 llvm-svn: 197645
2013-12-19 10:14:12 +08:00
call void @doit(i64* inalloca %a)
call void @doit(i64* inalloca %a)
ret void
}
Add an inalloca flag to allocas Summary: The only current use of this flag is to mark the alloca as dynamic, even if its in the entry block. The stack adjustment for the alloca can never be folded into the prologue because the call may clear it and it has to be allocated at the top of the stack. Reviewers: majnemer CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2571 llvm-svn: 199525
2014-01-18 07:58:17 +08:00
define void @c(i1 %cond) {
entry:
br i1 %cond, label %if, label %else
if:
IR: Change inalloca's grammar a bit The grammar for LLVM IR is not well specified in any document but seems to obey the following rules: - Attributes which have parenthesized arguments are never preceded by commas. This form of attribute is the only one which ever has optional arguments. However, not all of these attributes support optional arguments: 'thread_local' supports an optional argument but 'addrspace' does not. Interestingly, 'addrspace' is documented as being a "qualifier". What constitutes a qualifier? I cannot find a definition. - Some attributes use a space between the keyword and the value. Examples of this form are 'align' and 'section'. These are always preceded by a comma. - Otherwise, the attribute has no argument. These attributes do not have a preceding comma. Sometimes an attribute goes before the instruction, between the instruction and it's type, or after it's type. 'atomicrmw' has 'volatile' between the instruction and the type while 'call' has 'tail' preceding the instruction. With all this in mind, it seems most consistent for 'inalloca' on an 'inalloca' instruction to occur before between the instruction and the type. Unlike the current formulation, there would be no preceding comma. The combination 'alloca inalloca' doesn't look particularly appetizing, perhaps a better spelling of 'inalloca' is down the road. llvm-svn: 203376
2014-03-09 14:41:58 +08:00
%a = alloca inalloca i64
Add an inalloca flag to allocas Summary: The only current use of this flag is to mark the alloca as dynamic, even if its in the entry block. The stack adjustment for the alloca can never be folded into the prologue because the call may clear it and it has to be allocated at the top of the stack. Reviewers: majnemer CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2571 llvm-svn: 199525
2014-01-18 07:58:17 +08:00
br label %call
else:
IR: Change inalloca's grammar a bit The grammar for LLVM IR is not well specified in any document but seems to obey the following rules: - Attributes which have parenthesized arguments are never preceded by commas. This form of attribute is the only one which ever has optional arguments. However, not all of these attributes support optional arguments: 'thread_local' supports an optional argument but 'addrspace' does not. Interestingly, 'addrspace' is documented as being a "qualifier". What constitutes a qualifier? I cannot find a definition. - Some attributes use a space between the keyword and the value. Examples of this form are 'align' and 'section'. These are always preceded by a comma. - Otherwise, the attribute has no argument. These attributes do not have a preceding comma. Sometimes an attribute goes before the instruction, between the instruction and it's type, or after it's type. 'atomicrmw' has 'volatile' between the instruction and the type while 'call' has 'tail' preceding the instruction. With all this in mind, it seems most consistent for 'inalloca' on an 'inalloca' instruction to occur before between the instruction and the type. Unlike the current formulation, there would be no preceding comma. The combination 'alloca inalloca' doesn't look particularly appetizing, perhaps a better spelling of 'inalloca' is down the road. llvm-svn: 203376
2014-03-09 14:41:58 +08:00
%b = alloca inalloca i64
Add an inalloca flag to allocas Summary: The only current use of this flag is to mark the alloca as dynamic, even if its in the entry block. The stack adjustment for the alloca can never be folded into the prologue because the call may clear it and it has to be allocated at the top of the stack. Reviewers: majnemer CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2571 llvm-svn: 199525
2014-01-18 07:58:17 +08:00
br label %call
call:
%args = phi i64* [ %a, %if ], [ %b, %else ]
call void @doit(i64* inalloca %args)
ret void
}