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

289 lines
8.1 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] Introduce a pass to begin more systematically fixing PR36028 and similar issues. The key idea is to lower COPY nodes populating EFLAGS by scanning the uses of EFLAGS and introducing dedicated code to preserve the necessary state in a GPR. In the vast majority of cases, these uses are cmovCC and jCC instructions. For such cases, we can very easily save and restore the necessary information by simply inserting a setCC into a GPR where the original flags are live, and then testing that GPR directly to feed the cmov or conditional branch. However, things are a bit more tricky if arithmetic is using the flags. This patch handles the vast majority of cases that seem to come up in practice: adc, adcx, adox, rcl, and rcr; all without taking advantage of partially preserved EFLAGS as LLVM doesn't currently model that at all. There are a large number of operations that techinaclly observe EFLAGS currently but shouldn't in this case -- they typically are using DF. Currently, they will not be handled by this approach. However, I have never seen this issue come up in practice. It is already pretty rare to have these patterns come up in practical code with LLVM. I had to resort to writing MIR tests to cover most of the logic in this pass already. I suspect even with its current amount of coverage of arithmetic users of EFLAGS it will be a significant improvement over the current use of pushf/popf. It will also produce substantially faster code in most of the common patterns. This patch also removes all of the old lowering for EFLAGS copies, and the hack that forced us to use a frame pointer when EFLAGS copies were found anywhere in a function so that the dynamic stack adjustment wasn't a problem. None of this is needed as we now lower all of these copies directly in MI and without require stack adjustments. Lots of thanks to Reid who came up with several aspects of this approach, and Craig who helped me work out a couple of things tripping me up while working on this. Differential Revision: https://reviews.llvm.org/D45146 llvm-svn: 329657
2018-04-10 09:41:17 +08:00
; ALL-LABEL: f10:
; ALL: # %bb.0:
; ALL-NEXT: pushq %rsi
; ALL-NEXT: .seh_pushreg 6
; ALL-NEXT: pushq %rbx
; ALL-NEXT: .seh_pushreg 3
; ALL-NEXT: subq $40, %rsp
; ALL-NEXT: .seh_stackalloc 40
; ALL-NEXT: .seh_endprologue
; ALL-NEXT: movq %rdx, %rsi
; ALL-NEXT: movq %rdx, %rax
; ALL-NEXT: lock cmpxchgq %r8, (%rcx)
; ALL-NEXT: sete %bl
; ALL-NEXT: callq dummy
[x86] Switch EFLAGS copy lowering to use reg-reg form of testing for a zero register. Previously I tried this and saw LLVM unable to transform this to fold with memory operands such as spill slot rematerialization. However, it clearly works as shown in this patch. We turn these into `cmpb $0, <mem>` when useful for folding a memory operand without issue. This form has no disadvantage compared to `testb $-1, <mem>`. So overall, this is likely no worse and may be slightly smaller in some cases due to the `testb %reg, %reg` form. Differential Revision: https://reviews.llvm.org/D45475 llvm-svn: 330269
2018-04-18 23:52:50 +08:00
; ALL-NEXT: testb %bl, %bl
[x86] Introduce a pass to begin more systematically fixing PR36028 and similar issues. The key idea is to lower COPY nodes populating EFLAGS by scanning the uses of EFLAGS and introducing dedicated code to preserve the necessary state in a GPR. In the vast majority of cases, these uses are cmovCC and jCC instructions. For such cases, we can very easily save and restore the necessary information by simply inserting a setCC into a GPR where the original flags are live, and then testing that GPR directly to feed the cmov or conditional branch. However, things are a bit more tricky if arithmetic is using the flags. This patch handles the vast majority of cases that seem to come up in practice: adc, adcx, adox, rcl, and rcr; all without taking advantage of partially preserved EFLAGS as LLVM doesn't currently model that at all. There are a large number of operations that techinaclly observe EFLAGS currently but shouldn't in this case -- they typically are using DF. Currently, they will not be handled by this approach. However, I have never seen this issue come up in practice. It is already pretty rare to have these patterns come up in practical code with LLVM. I had to resort to writing MIR tests to cover most of the logic in this pass already. I suspect even with its current amount of coverage of arithmetic users of EFLAGS it will be a significant improvement over the current use of pushf/popf. It will also produce substantially faster code in most of the common patterns. This patch also removes all of the old lowering for EFLAGS copies, and the hack that forced us to use a frame pointer when EFLAGS copies were found anywhere in a function so that the dynamic stack adjustment wasn't a problem. None of this is needed as we now lower all of these copies directly in MI and without require stack adjustments. Lots of thanks to Reid who came up with several aspects of this approach, and Craig who helped me work out a couple of things tripping me up while working on this. Differential Revision: https://reviews.llvm.org/D45146 llvm-svn: 329657
2018-04-10 09:41:17 +08:00
; ALL-NEXT: cmoveq %rsi, %rax
; ALL-NEXT: addq $40, %rsp
; ALL-NEXT: popq %rbx
; ALL-NEXT: popq %rsi
; 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
%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