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

331 lines
9.3 KiB
LLVM
Raw Normal View History

[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=x86_64-pc-win32 | FileCheck %s --check-prefix=ALL --check-prefix=PUSHF
; RUN: llc < %s -mtriple=x86_64-pc-win32 -mattr=+sahf | FileCheck %s --check-prefix=ALL --check-prefix=SAHF
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
define i32 @f1(i32 %p1, i32 %p2, i32 %p3, i32 %p4, i32 %p5) "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f1:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: movq %rsp, %rbp
; ALL-NEXT: .seh_setframe 5, 0
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: movl 48(%rbp), %eax
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
ret i32 %p5
}
define void @f2(i32 %p, ...) "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f2:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: pushq %rax
; ALL-NEXT: .seh_stackalloc 8
; ALL-NEXT: movq %rsp, %rbp
; ALL-NEXT: .seh_setframe 5, 0
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: movq %r9, 48(%rbp)
; ALL-NEXT: movq %r8, 40(%rbp)
; ALL-NEXT: movq %rdx, 32(%rbp)
; ALL-NEXT: leaq 32(%rbp), %rax
; ALL-NEXT: movq %rax, (%rbp)
; ALL-NEXT: addq $8, %rsp
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
%ap = alloca i8, align 8
call void @llvm.va_start(i8* %ap)
ret void
}
define i8* @f3() "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f3:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: movq %rsp, %rbp
; ALL-NEXT: .seh_setframe 5, 0
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: movq 8(%rbp), %rax
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
%ra = call i8* @llvm.returnaddress(i32 0)
ret i8* %ra
}
define i8* @f4() "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f4:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: subq $304, %rsp # imm = 0x130
; ALL-NEXT: .seh_stackalloc 304
; ALL-NEXT: leaq {{[0-9]+}}(%rsp), %rbp
; ALL-NEXT: .seh_setframe 5, 128
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: movq 184(%rbp), %rax
; ALL-NEXT: addq $304, %rsp # imm = 0x130
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
alloca [300 x i8]
%ra = call i8* @llvm.returnaddress(i32 0)
ret i8* %ra
}
declare void @external(i8*)
define void @f5() "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f5:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: subq $336, %rsp # imm = 0x150
; ALL-NEXT: .seh_stackalloc 336
; ALL-NEXT: leaq {{[0-9]+}}(%rsp), %rbp
; ALL-NEXT: .seh_setframe 5, 128
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: leaq -92(%rbp), %rcx
; ALL-NEXT: callq external
; ALL-NEXT: nop
; ALL-NEXT: addq $336, %rsp # imm = 0x150
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
%a = alloca [300 x i8]
[opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction One of several parallel first steps to remove the target type of pointers, replacing them with a single opaque pointer type. This adds an explicit type parameter to the gep instruction so that when the first parameter becomes an opaque pointer type, the type to gep through is still available to the instructions. * This doesn't modify gep operators, only instructions (operators will be handled separately) * Textual IR changes only. Bitcode (including upgrade) and changing the in-memory representation will be in separate changes. * geps of vectors are transformed as: getelementptr <4 x float*> %x, ... ->getelementptr float, <4 x float*> %x, ... Then, once the opaque pointer type is introduced, this will ultimately look like: getelementptr float, <4 x ptr> %x with the unambiguous interpretation that it is a vector of pointers to float. * address spaces remain on the pointer, not the type: getelementptr float addrspace(1)* %x ->getelementptr float, float addrspace(1)* %x Then, eventually: getelementptr float, ptr addrspace(1) %x Importantly, the massive amount of test case churn has been automated by same crappy python code. I had to manually update a few test cases that wouldn't fit the script's model (r228970,r229196,r229197,r229198). The python script just massages stdin and writes the result to stdout, I then wrapped that in a shell script to handle replacing files, then using the usual find+xargs to migrate all the files. update.py: import fileinput import sys import re ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") def conv(match, line): if not match: return line line = match.groups()[0] if len(match.groups()[5]) == 0: line += match.groups()[2] line += match.groups()[3] line += ", " line += match.groups()[1] line += "\n" return line for line in sys.stdin: if line.find("getelementptr ") == line.find("getelementptr inbounds"): if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("): line = conv(re.match(ibrep, line), line) elif line.find("getelementptr ") != line.find("getelementptr ("): line = conv(re.match(normrep, line), line) sys.stdout.write(line) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh After that, check-all (with llvm, clang, clang-tools-extra, lld, compiler-rt, and polly all checked out). The extra 'rm' in the apply.sh script is due to a few files in clang's test suite using interesting unicode stuff that my python script was throwing exceptions on. None of those files needed to be migrated, so it seemed sufficient to ignore those cases. Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7636 llvm-svn: 230786
2015-02-28 03:29:02 +08:00
%gep = getelementptr [300 x i8], [300 x i8]* %a, i32 0, i32 0
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
call void @external(i8* %gep)
ret void
}
define void @f6(i32 %p, ...) "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f6:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: subq $336, %rsp # imm = 0x150
; ALL-NEXT: .seh_stackalloc 336
; ALL-NEXT: leaq {{[0-9]+}}(%rsp), %rbp
; ALL-NEXT: .seh_setframe 5, 128
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: leaq -92(%rbp), %rcx
; ALL-NEXT: callq external
; ALL-NEXT: nop
; ALL-NEXT: addq $336, %rsp # imm = 0x150
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
%a = alloca [300 x i8]
[opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction One of several parallel first steps to remove the target type of pointers, replacing them with a single opaque pointer type. This adds an explicit type parameter to the gep instruction so that when the first parameter becomes an opaque pointer type, the type to gep through is still available to the instructions. * This doesn't modify gep operators, only instructions (operators will be handled separately) * Textual IR changes only. Bitcode (including upgrade) and changing the in-memory representation will be in separate changes. * geps of vectors are transformed as: getelementptr <4 x float*> %x, ... ->getelementptr float, <4 x float*> %x, ... Then, once the opaque pointer type is introduced, this will ultimately look like: getelementptr float, <4 x ptr> %x with the unambiguous interpretation that it is a vector of pointers to float. * address spaces remain on the pointer, not the type: getelementptr float addrspace(1)* %x ->getelementptr float, float addrspace(1)* %x Then, eventually: getelementptr float, ptr addrspace(1) %x Importantly, the massive amount of test case churn has been automated by same crappy python code. I had to manually update a few test cases that wouldn't fit the script's model (r228970,r229196,r229197,r229198). The python script just massages stdin and writes the result to stdout, I then wrapped that in a shell script to handle replacing files, then using the usual find+xargs to migrate all the files. update.py: import fileinput import sys import re ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") def conv(match, line): if not match: return line line = match.groups()[0] if len(match.groups()[5]) == 0: line += match.groups()[2] line += match.groups()[3] line += ", " line += match.groups()[1] line += "\n" return line for line in sys.stdin: if line.find("getelementptr ") == line.find("getelementptr inbounds"): if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("): line = conv(re.match(ibrep, line), line) elif line.find("getelementptr ") != line.find("getelementptr ("): line = conv(re.match(normrep, line), line) sys.stdout.write(line) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh After that, check-all (with llvm, clang, clang-tools-extra, lld, compiler-rt, and polly all checked out). The extra 'rm' in the apply.sh script is due to a few files in clang's test suite using interesting unicode stuff that my python script was throwing exceptions on. None of those files needed to be migrated, so it seemed sufficient to ignore those cases. Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7636 llvm-svn: 230786
2015-02-28 03:29:02 +08:00
%gep = getelementptr [300 x i8], [300 x i8]* %a, i32 0, i32 0
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
call void @external(i8* %gep)
ret void
}
define i32 @f7(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e) "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f7:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: subq $304, %rsp # imm = 0x130
; ALL-NEXT: .seh_stackalloc 304
; ALL-NEXT: leaq {{[0-9]+}}(%rsp), %rbp
; ALL-NEXT: .seh_setframe 5, 128
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: andq $-64, %rsp
; ALL-NEXT: movl 224(%rbp), %eax
; ALL-NEXT: leaq 176(%rbp), %rsp
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
alloca [300 x i8], align 64
ret i32 %e
}
define i32 @f8(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e) "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f8:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: pushq %rsi
; ALL-NEXT: .seh_pushreg 6
; ALL-NEXT: pushq %rbx
; ALL-NEXT: .seh_pushreg 3
; ALL-NEXT: subq $352, %rsp # imm = 0x160
; ALL-NEXT: .seh_stackalloc 352
; ALL-NEXT: leaq {{[0-9]+}}(%rsp), %rbp
; ALL-NEXT: .seh_setframe 5, 128
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: andq $-64, %rsp
; ALL-NEXT: movq %rsp, %rbx
; ALL-NEXT: movl 288(%rbp), %esi
; ALL-NEXT: movl %ecx, %eax
[x86] shrink 'and' immediate values by setting the high bits (PR35907) Try to reverse the constant-shrinking that happens in SimplifyDemandedBits() for 'and' masks when it results in a smaller sign-extended immediate. We are also able to detect dead 'and' ops here (the mask is all ones). In that case, we replace and return without selecting the 'and'. Other targets might want to share some of this logic by enabling this under a target hook, but I didn't see diffs for simple cases with PowerPC or AArch64, so they may already have some specialized logic for this kind of thing or have different needs. This should solve PR35907: https://bugs.llvm.org/show_bug.cgi?id=35907 Differential Revision: https://reviews.llvm.org/D42088 llvm-svn: 322957
2018-01-20 00:37:25 +08:00
; ALL-NEXT: leaq 15(,%rax,4), %rax
; ALL-NEXT: andq $-16, %rax
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-NEXT: callq __chkstk
; ALL-NEXT: subq %rax, %rsp
; ALL-NEXT: subq $32, %rsp
; ALL-NEXT: movq %rbx, %rcx
; ALL-NEXT: callq external
; ALL-NEXT: addq $32, %rsp
; ALL-NEXT: movl %esi, %eax
; ALL-NEXT: leaq 224(%rbp), %rsp
; ALL-NEXT: popq %rbx
; ALL-NEXT: popq %rsi
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
%alloca = alloca [300 x i8], align 64
alloca i32, i32 %a
[opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction One of several parallel first steps to remove the target type of pointers, replacing them with a single opaque pointer type. This adds an explicit type parameter to the gep instruction so that when the first parameter becomes an opaque pointer type, the type to gep through is still available to the instructions. * This doesn't modify gep operators, only instructions (operators will be handled separately) * Textual IR changes only. Bitcode (including upgrade) and changing the in-memory representation will be in separate changes. * geps of vectors are transformed as: getelementptr <4 x float*> %x, ... ->getelementptr float, <4 x float*> %x, ... Then, once the opaque pointer type is introduced, this will ultimately look like: getelementptr float, <4 x ptr> %x with the unambiguous interpretation that it is a vector of pointers to float. * address spaces remain on the pointer, not the type: getelementptr float addrspace(1)* %x ->getelementptr float, float addrspace(1)* %x Then, eventually: getelementptr float, ptr addrspace(1) %x Importantly, the massive amount of test case churn has been automated by same crappy python code. I had to manually update a few test cases that wouldn't fit the script's model (r228970,r229196,r229197,r229198). The python script just massages stdin and writes the result to stdout, I then wrapped that in a shell script to handle replacing files, then using the usual find+xargs to migrate all the files. update.py: import fileinput import sys import re ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") def conv(match, line): if not match: return line line = match.groups()[0] if len(match.groups()[5]) == 0: line += match.groups()[2] line += match.groups()[3] line += ", " line += match.groups()[1] line += "\n" return line for line in sys.stdin: if line.find("getelementptr ") == line.find("getelementptr inbounds"): if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("): line = conv(re.match(ibrep, line), line) elif line.find("getelementptr ") != line.find("getelementptr ("): line = conv(re.match(normrep, line), line) sys.stdout.write(line) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh After that, check-all (with llvm, clang, clang-tools-extra, lld, compiler-rt, and polly all checked out). The extra 'rm' in the apply.sh script is due to a few files in clang's test suite using interesting unicode stuff that my python script was throwing exceptions on. None of those files needed to be migrated, so it seemed sufficient to ignore those cases. Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7636 llvm-svn: 230786
2015-02-28 03:29:02 +08:00
%gep = getelementptr [300 x i8], [300 x i8]* %alloca, i32 0, i32 0
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
call void @external(i8* %gep)
ret i32 %e
}
[X86, Win64] Use a frame pointer if pushf is emitted A frame pointer must be used if stack pointer is modified after the prologue. LLVM will emit pushf/popf if we need to save/restore the FLAGS register, requiring us to have a frame pointer for the function. There is a small twist: this sequence might exist in user code via inline-assembly. For now, conservatively assume that such functions require a frame pointer. For real world justification, please see clang's implementation of __readeflags. This fixes PR25945. llvm-svn: 256456
2015-12-27 14:07:26 +08:00
define i64 @f9() {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f9:
; ALL: # %bb.0: # %entry
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: movq %rsp, %rbp
; ALL-NEXT: .seh_setframe 5, 0
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: pushfq
; ALL-NEXT: popq %rax
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
[X86, Win64] Use a frame pointer if pushf is emitted A frame pointer must be used if stack pointer is modified after the prologue. LLVM will emit pushf/popf if we need to save/restore the FLAGS register, requiring us to have a frame pointer for the function. There is a small twist: this sequence might exist in user code via inline-assembly. For now, conservatively assume that such functions require a frame pointer. For real world justification, please see clang's implementation of __readeflags. This fixes PR25945. llvm-svn: 256456
2015-12-27 14:07:26 +08:00
entry:
[X86] Add intrinsics for reading and writing to the flags register LLVM's targets need to know if stack pointer adjustments occur after the prologue. This is needed to correctly determine if the red-zone is appropriate to use or if a frame pointer is required. Normally, LLVM can figure this out very precisely by reasoning about the contents of the MachineFunction. There is an interesting corner case: inline assembly. The vast majority of inline assembly which will perform a push or pop is done so to pair up with pushf or popf as appropriate. Unfortunately, this inline assembly doesn't mark the stack pointer as clobbered because, well, it isn't. The stack pointer is decremented and then immediately incremented. Because of this, LLVM was changed in r256456 to conservatively assume that inline assembly contain a sequence of stack operations. This is unfortunate because the vast majority of inline assembly will not end up manipulating the stack pointer in any way at all. Instead, let's provide a more principled solution: an intrinsic. FWIW, other compilers (MSVC and GCC among them) also provide this functionality as an intrinsic. llvm-svn: 256685
2016-01-01 14:50:01 +08:00
%call = call i64 @llvm.x86.flags.read.u64()
[X86, Win64] Use a frame pointer if pushf is emitted A frame pointer must be used if stack pointer is modified after the prologue. LLVM will emit pushf/popf if we need to save/restore the FLAGS register, requiring us to have a frame pointer for the function. There is a small twist: this sequence might exist in user code via inline-assembly. For now, conservatively assume that such functions require a frame pointer. For real world justification, please see clang's implementation of __readeflags. This fixes PR25945. llvm-svn: 256456
2015-12-27 14:07:26 +08:00
ret i64 %call
}
declare i64 @dummy()
define i64 @f10(i64* %foo, i64 %bar, i64 %baz) {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; PUSHF-LABEL: f10:
; PUSHF: # %bb.0:
; PUSHF-NEXT: pushq %rbp
; PUSHF-NEXT: .seh_pushreg 5
; PUSHF-NEXT: pushq %rsi
; PUSHF-NEXT: .seh_pushreg 6
; PUSHF-NEXT: pushq %rdi
; PUSHF-NEXT: .seh_pushreg 7
; PUSHF-NEXT: subq $32, %rsp
; PUSHF-NEXT: .seh_stackalloc 32
; PUSHF-NEXT: leaq {{[0-9]+}}(%rsp), %rbp
; PUSHF-NEXT: .seh_setframe 5, 32
; PUSHF-NEXT: .seh_endprologue
; PUSHF-NEXT: movq %rdx, %rsi
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; PUSHF-NEXT: movq %rdx, %rax
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; PUSHF-NEXT: lock cmpxchgq %r8, (%rcx)
; PUSHF-NEXT: pushfq
; PUSHF-NEXT: popq %rdi
; PUSHF-NEXT: callq dummy
; PUSHF-NEXT: pushq %rdi
; PUSHF-NEXT: popfq
; PUSHF-NEXT: cmovneq %rsi, %rax
; PUSHF-NEXT: addq $32, %rsp
; PUSHF-NEXT: popq %rdi
; PUSHF-NEXT: popq %rsi
; PUSHF-NEXT: popq %rbp
; PUSHF-NEXT: retq
; PUSHF-NEXT: .seh_handlerdata
; PUSHF-NEXT: .text
; PUSHF-NEXT: .seh_endproc
;
; SAHF-LABEL: f10:
; SAHF: # %bb.0:
; SAHF-NEXT: pushq %rbp
; SAHF-NEXT: .seh_pushreg 5
; SAHF-NEXT: pushq %rsi
; SAHF-NEXT: .seh_pushreg 6
; SAHF-NEXT: pushq %rdi
; SAHF-NEXT: .seh_pushreg 7
; SAHF-NEXT: subq $32, %rsp
; SAHF-NEXT: .seh_stackalloc 32
; SAHF-NEXT: leaq {{[0-9]+}}(%rsp), %rbp
; SAHF-NEXT: .seh_setframe 5, 32
; SAHF-NEXT: .seh_endprologue
; SAHF-NEXT: movq %rdx, %rsi
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; SAHF-NEXT: movq %rdx, %rax
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; SAHF-NEXT: lock cmpxchgq %r8, (%rcx)
; SAHF-NEXT: seto %al
; SAHF-NEXT: lahf
; SAHF-NEXT: movq %rax, %rdi
; SAHF-NEXT: callq dummy
; SAHF-NEXT: pushq %rax
; SAHF-NEXT: movq %rdi, %rax
; SAHF-NEXT: addb $127, %al
; SAHF-NEXT: sahf
; SAHF-NEXT: popq %rax
; SAHF-NEXT: cmovneq %rsi, %rax
; SAHF-NEXT: addq $32, %rsp
; SAHF-NEXT: popq %rdi
; SAHF-NEXT: popq %rsi
; SAHF-NEXT: popq %rbp
; SAHF-NEXT: retq
; SAHF-NEXT: .seh_handlerdata
; SAHF-NEXT: .text
; SAHF-NEXT: .seh_endproc
[X86, Win64] Use a frame pointer if pushf is emitted A frame pointer must be used if stack pointer is modified after the prologue. LLVM will emit pushf/popf if we need to save/restore the FLAGS register, requiring us to have a frame pointer for the function. There is a small twist: this sequence might exist in user code via inline-assembly. For now, conservatively assume that such functions require a frame pointer. For real world justification, please see clang's implementation of __readeflags. This fixes PR25945. llvm-svn: 256456
2015-12-27 14:07:26 +08:00
%cx = cmpxchg i64* %foo, i64 %bar, i64 %baz seq_cst seq_cst
%v = extractvalue { i64, i1 } %cx, 0
%p = extractvalue { i64, i1 } %cx, 1
%call = call i64 @dummy()
%sel = select i1 %p, i64 %call, i64 %bar
ret i64 %sel
}
Create llvm.addressofreturnaddress intrinsic Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25293 llvm-svn: 284061
2016-10-13 06:13:19 +08:00
define i8* @f11() "no-frame-pointer-elim"="true" {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f11:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rbp
; ALL-NEXT: .seh_pushreg 5
; ALL-NEXT: movq %rsp, %rbp
; ALL-NEXT: .seh_setframe 5, 0
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: leaq 8(%rbp), %rax
; ALL-NEXT: popq %rbp
; ALL-NEXT: retq
; ALL-NEXT: .seh_handlerdata
; ALL-NEXT: .text
; ALL-NEXT: .seh_endproc
Create llvm.addressofreturnaddress intrinsic Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25293 llvm-svn: 284061
2016-10-13 06:13:19 +08:00
%aora = call i8* @llvm.addressofreturnaddress()
ret i8* %aora
}
define i8* @f12() {
[x86] regenerate test checks; NFC llvm-svn: 322521
2018-01-16 05:28:52 +08:00
; ALL-LABEL: f12:
; ALL: # %bb.0:
; ALL-NEXT: movq %rsp, %rax
; ALL-NEXT: retq
Create llvm.addressofreturnaddress intrinsic Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25293 llvm-svn: 284061
2016-10-13 06:13:19 +08:00
%aora = call i8* @llvm.addressofreturnaddress()
ret i8* %aora
}
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
declare i8* @llvm.returnaddress(i32) nounwind readnone
Create llvm.addressofreturnaddress intrinsic Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25293 llvm-svn: 284061
2016-10-13 06:13:19 +08:00
declare i8* @llvm.addressofreturnaddress() nounwind readnone
[X86] Add intrinsics for reading and writing to the flags register LLVM's targets need to know if stack pointer adjustments occur after the prologue. This is needed to correctly determine if the red-zone is appropriate to use or if a frame pointer is required. Normally, LLVM can figure this out very precisely by reasoning about the contents of the MachineFunction. There is an interesting corner case: inline assembly. The vast majority of inline assembly which will perform a push or pop is done so to pair up with pushf or popf as appropriate. Unfortunately, this inline assembly doesn't mark the stack pointer as clobbered because, well, it isn't. The stack pointer is decremented and then immediately incremented. Because of this, LLVM was changed in r256456 to conservatively assume that inline assembly contain a sequence of stack operations. This is unfortunate because the vast majority of inline assembly will not end up manipulating the stack pointer in any way at all. Instead, let's provide a more principled solution: an intrinsic. FWIW, other compilers (MSVC and GCC among them) also provide this functionality as an intrinsic. llvm-svn: 256685
2016-01-01 14:50:01 +08:00
declare i64 @llvm.x86.flags.read.u64()
X86: Emit an ABI compliant prologue and epilogue for Win64 Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
2015-02-10 08:57:42 +08:00
declare void @llvm.va_start(i8*) nounwind