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/switch-bt.ll

158 lines
3.7 KiB
LLVM
Raw Normal View History

Optimize the "bit test" code path for switch lowering in the case where the bit mask has exactly one bit. llvm-svn: 106716
2010-06-24 10:06:24 +08:00
; RUN: llc -march=x86-64 -asm-verbose=false < %s | FileCheck %s
; This switch should use bit tests, and the third bit test case is just
; testing for one possible value, so it doesn't need a bt.
; CHECK: movabsq $2305843009482129440, %r
; CHECK-NEXT: btq %rax, %r
Distribute the weight on the edge from switch to default statement to edges generated in lowering switch. Currently, when edge weights are assigned to edges that are created when lowering switch statement, the weight on the edge to default statement (let's call it "default weight" here) is not considered. We need to distribute this weight properly. However, without value profiling, we have no idea how to distribute it. In this patch, I applied the heuristic that this weight is evenly distributed to successors. For example, given a switch statement with cases 1,2,3,5,10,11,20, and every edge from switch to each successor has weight 10. If there is a binary search tree built to test if n < 10, then its two out-edges will have weight 4x10+10/2 = 45 and 3x10 + 10/2 = 35 respectively (currently they are 40 and 30 without considering the default weight). Each distribution (which is 5 here) will be stored in each SwitchWorkListItem for further distribution. There are some exceptions: For a jump table header which doesn't have any edge to default statement, we don't distribute the default weight to it. For a bit test header which covers a contiguous range and hence has no edges to default statement, we don't distribute the default weight to it. When the branch checks a single value or a contiguous range with no edge to default statement, we don't distribute the default weight to it. In other cases, the default weight is evenly distributed to successors. Differential Revision: http://reviews.llvm.org/D12418 llvm-svn: 246522
2015-09-01 09:42:16 +08:00
; CHECK-NEXT: jb
Flip the new block-placement pass to be on by default. This is mostly to test the waters. I'd like to get results from FNT build bots and other bots running on non-x86 platforms. This feature has been pretty heavily tested over the last few months by me, and it fixes several of the execution time regressions caused by the inlining work by preventing inlining decisions from radically impacting block layout. I've seen very large improvements in yacr2 and ackermann benchmarks, along with the expected noise across all of the benchmark suite whenever code layout changes. I've analyzed all of the regressions and fixed them, or found them to be impossible to fix. See my email to llvmdev for more details. I'd like for this to be in 3.1 as it complements the inliner changes, but if any failures are showing up or anyone has concerns, it is just a flag flip and so can be easily turned off. I'm switching it on tonight to try and get at least one run through various folks' performance suites in case SPEC or something else has serious issues with it. I'll watch bots and revert if anything shows up. llvm-svn: 154816
2012-04-16 21:49:17 +08:00
; CHECK: movl $671088640, %e
Optimize the "bit test" code path for switch lowering in the case where the bit mask has exactly one bit. llvm-svn: 106716
2010-06-24 10:06:24 +08:00
; CHECK-NEXT: btq %rax, %r
Flip the new block-placement pass to be on by default. This is mostly to test the waters. I'd like to get results from FNT build bots and other bots running on non-x86 platforms. This feature has been pretty heavily tested over the last few months by me, and it fixes several of the execution time regressions caused by the inlining work by preventing inlining decisions from radically impacting block layout. I've seen very large improvements in yacr2 and ackermann benchmarks, along with the expected noise across all of the benchmark suite whenever code layout changes. I've analyzed all of the regressions and fixed them, or found them to be impossible to fix. See my email to llvmdev for more details. I'd like for this to be in 3.1 as it complements the inliner changes, but if any failures are showing up or anyone has concerns, it is just a flag flip and so can be easily turned off. I'm switching it on tonight to try and get at least one run through various folks' performance suites in case SPEC or something else has serious issues with it. I'll watch bots and revert if anything shows up. llvm-svn: 154816
2012-04-16 21:49:17 +08:00
; CHECK-NEXT: jae
; CHECK: testq %rax, %r
Optimize the "bit test" code path for switch lowering in the case where the bit mask has exactly one bit. llvm-svn: 106716
2010-06-24 10:06:24 +08:00
; CHECK-NEXT: j
define void @test(i8* %l) nounwind {
entry:
%l.addr = alloca i8*, align 8 ; <i8**> [#uses=2]
store i8* %l, i8** %l.addr
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%tmp = load i8*, i8** %l.addr ; <i8*> [#uses=1]
%tmp1 = load i8, i8* %tmp ; <i8> [#uses=1]
Optimize the "bit test" code path for switch lowering in the case where the bit mask has exactly one bit. llvm-svn: 106716
2010-06-24 10:06:24 +08:00
%conv = sext i8 %tmp1 to i32 ; <i32> [#uses=1]
switch i32 %conv, label %sw.default [
i32 62, label %sw.bb
i32 60, label %sw.bb
i32 38, label %sw.bb2
i32 94, label %sw.bb2
i32 61, label %sw.bb2
i32 33, label %sw.bb4
]
sw.bb: ; preds = %entry, %entry
call void @foo(i32 0)
br label %sw.epilog
sw.bb2: ; preds = %entry, %entry, %entry
call void @foo(i32 1)
br label %sw.epilog
sw.bb4: ; preds = %entry
call void @foo(i32 3)
br label %sw.epilog
sw.default: ; preds = %entry
call void @foo(i32 97)
br label %sw.epilog
sw.epilog: ; preds = %sw.default, %sw.bb4, %sw.bb2, %sw.bb
ret void
}
declare void @foo(i32)
Avoid zero extend bit test operands to pointer type if all the masks fit in the original type of the switch statement key. rdar://8781238 llvm-svn: 122935
2011-01-06 09:02:44 +08:00
; Don't zero extend the test operands to pointer type if it can be avoided.
; rdar://8781238
define void @test2(i32 %x) nounwind ssp {
Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier debugging. No functionality change and all tests pass after conversion. This was done with the following sed invocation to catch label lines demarking function boundaries: sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct. llvm-svn: 186258
2013-07-14 04:38:47 +08:00
; CHECK-LABEL: test2:
Avoid zero extend bit test operands to pointer type if all the masks fit in the original type of the switch statement key. rdar://8781238 llvm-svn: 122935
2011-01-06 09:02:44 +08:00
; CHECK: cmpl $6
; CHECK: ja
; CHECK-NEXT: movl $91
; CHECK-NOT: movl
; CHECK-NEXT: btl
Flip the new block-placement pass to be on by default. This is mostly to test the waters. I'd like to get results from FNT build bots and other bots running on non-x86 platforms. This feature has been pretty heavily tested over the last few months by me, and it fixes several of the execution time regressions caused by the inlining work by preventing inlining decisions from radically impacting block layout. I've seen very large improvements in yacr2 and ackermann benchmarks, along with the expected noise across all of the benchmark suite whenever code layout changes. I've analyzed all of the regressions and fixed them, or found them to be impossible to fix. See my email to llvmdev for more details. I'd like for this to be in 3.1 as it complements the inliner changes, but if any failures are showing up or anyone has concerns, it is just a flag flip and so can be easily turned off. I'm switching it on tonight to try and get at least one run through various folks' performance suites in case SPEC or something else has serious issues with it. I'll watch bots and revert if anything shows up. llvm-svn: 154816
2012-04-16 21:49:17 +08:00
; CHECK-NEXT: jae
Avoid zero extend bit test operands to pointer type if all the masks fit in the original type of the switch statement key. rdar://8781238 llvm-svn: 122935
2011-01-06 09:02:44 +08:00
entry:
switch i32 %x, label %if.end [
i32 6, label %if.then
i32 4, label %if.then
i32 3, label %if.then
i32 1, label %if.then
i32 0, label %if.then
]
if.then: ; preds = %entry, %entry, %entry, %entry, %entry
tail call void @bar() nounwind
ret void
if.end: ; preds = %entry
ret void
}
declare void @bar()
Don't emit a bit test if there is only one case the test can yield false. A simple SETNE is sufficient. llvm-svn: 135126
2011-07-14 09:38:42 +08:00
define void @test3(i32 %x) nounwind {
Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier debugging. No functionality change and all tests pass after conversion. This was done with the following sed invocation to catch label lines demarking function boundaries: sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct. llvm-svn: 186258
2013-07-14 04:38:47 +08:00
; CHECK-LABEL: test3:
Don't emit a bit test if there is only one case the test can yield false. A simple SETNE is sufficient. llvm-svn: 135126
2011-07-14 09:38:42 +08:00
; CHECK: cmpl $5
; CHECK: ja
; CHECK: cmpl $4
Flip the new block-placement pass to be on by default. This is mostly to test the waters. I'd like to get results from FNT build bots and other bots running on non-x86 platforms. This feature has been pretty heavily tested over the last few months by me, and it fixes several of the execution time regressions caused by the inlining work by preventing inlining decisions from radically impacting block layout. I've seen very large improvements in yacr2 and ackermann benchmarks, along with the expected noise across all of the benchmark suite whenever code layout changes. I've analyzed all of the regressions and fixed them, or found them to be impossible to fix. See my email to llvmdev for more details. I'd like for this to be in 3.1 as it complements the inliner changes, but if any failures are showing up or anyone has concerns, it is just a flag flip and so can be easily turned off. I'm switching it on tonight to try and get at least one run through various folks' performance suites in case SPEC or something else has serious issues with it. I'll watch bots and revert if anything shows up. llvm-svn: 154816
2012-04-16 21:49:17 +08:00
; CHECK: je
Don't emit a bit test if there is only one case the test can yield false. A simple SETNE is sufficient. llvm-svn: 135126
2011-07-14 09:38:42 +08:00
switch i32 %x, label %if.end [
i32 0, label %if.then
i32 1, label %if.then
i32 2, label %if.then
i32 3, label %if.then
i32 5, label %if.then
]
if.then:
tail call void @bar() nounwind
ret void
if.end:
ret void
}
Prevent binary-tree deterioration in sparse switch statements. This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
2015-01-21 03:43:33 +08:00
; Ensure that optimizing for jump tables doesn't needlessly deteriorate the
; created binary tree search. See PR22262.
define void @test4(i32 %x, i32* %y) {
; CHECK-LABEL: test4:
entry:
switch i32 %x, label %sw.default [
i32 10, label %sw.bb
i32 20, label %sw.bb1
i32 30, label %sw.bb2
i32 40, label %sw.bb3
i32 50, label %sw.bb4
i32 60, label %sw.bb5
]
sw.bb:
store i32 1, i32* %y
br label %sw.epilog
sw.bb1:
store i32 2, i32* %y
br label %sw.epilog
sw.bb2:
store i32 3, i32* %y
br label %sw.epilog
sw.bb3:
store i32 4, i32* %y
br label %sw.epilog
sw.bb4:
store i32 5, i32* %y
br label %sw.epilog
sw.bb5:
store i32 6, i32* %y
br label %sw.epilog
sw.default:
store i32 7, i32* %y
br label %sw.epilog
sw.epilog:
ret void
; The balanced binary switch here would start with a comparison against 39, but
; it is currently starting with 29 because of the density-sum heuristic.
Re-commit r235560: Switch lowering: extract jump tables and bit tests before building binary tree (PR22262) Third time's the charm. The previous commit was reverted as a reverse for-loop in SelectionDAGBuilder::lowerWorkItem did 'I--' on an iterator at the beginning of a vector, causing asserts when using debugging iterators. This commit fixes that. llvm-svn: 235608
2015-04-24 00:45:24 +08:00
; CHECK: cmpl $39
Prevent binary-tree deterioration in sparse switch statements. This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
2015-01-21 03:43:33 +08:00
; CHECK: jg
; CHECK: cmpl $10
Re-commit r235560: Switch lowering: extract jump tables and bit tests before building binary tree (PR22262) Third time's the charm. The previous commit was reverted as a reverse for-loop in SelectionDAGBuilder::lowerWorkItem did 'I--' on an iterator at the beginning of a vector, causing asserts when using debugging iterators. This commit fixes that. llvm-svn: 235608
2015-04-24 00:45:24 +08:00
; CHECK: je
Prevent binary-tree deterioration in sparse switch statements. This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
2015-01-21 03:43:33 +08:00
; CHECK: cmpl $20
Distribute the weight on the edge from switch to default statement to edges generated in lowering switch. Currently, when edge weights are assigned to edges that are created when lowering switch statement, the weight on the edge to default statement (let's call it "default weight" here) is not considered. We need to distribute this weight properly. However, without value profiling, we have no idea how to distribute it. In this patch, I applied the heuristic that this weight is evenly distributed to successors. For example, given a switch statement with cases 1,2,3,5,10,11,20, and every edge from switch to each successor has weight 10. If there is a binary search tree built to test if n < 10, then its two out-edges will have weight 4x10+10/2 = 45 and 3x10 + 10/2 = 35 respectively (currently they are 40 and 30 without considering the default weight). Each distribution (which is 5 here) will be stored in each SwitchWorkListItem for further distribution. There are some exceptions: For a jump table header which doesn't have any edge to default statement, we don't distribute the default weight to it. For a bit test header which covers a contiguous range and hence has no edges to default statement, we don't distribute the default weight to it. When the branch checks a single value or a contiguous range with no edge to default statement, we don't distribute the default weight to it. In other cases, the default weight is evenly distributed to successors. Differential Revision: http://reviews.llvm.org/D12418 llvm-svn: 246522
2015-09-01 09:42:16 +08:00
; CHECK: je
; CHECK: cmpl $30
Prevent binary-tree deterioration in sparse switch statements. This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
2015-01-21 03:43:33 +08:00
; CHECK: jne
Re-commit r235560: Switch lowering: extract jump tables and bit tests before building binary tree (PR22262) Third time's the charm. The previous commit was reverted as a reverse for-loop in SelectionDAGBuilder::lowerWorkItem did 'I--' on an iterator at the beginning of a vector, causing asserts when using debugging iterators. This commit fixes that. llvm-svn: 235608
2015-04-24 00:45:24 +08:00
; CHECK: cmpl $40
; CHECK: je
Prevent binary-tree deterioration in sparse switch statements. This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
2015-01-21 03:43:33 +08:00
; CHECK: cmpl $50
Distribute the weight on the edge from switch to default statement to edges generated in lowering switch. Currently, when edge weights are assigned to edges that are created when lowering switch statement, the weight on the edge to default statement (let's call it "default weight" here) is not considered. We need to distribute this weight properly. However, without value profiling, we have no idea how to distribute it. In this patch, I applied the heuristic that this weight is evenly distributed to successors. For example, given a switch statement with cases 1,2,3,5,10,11,20, and every edge from switch to each successor has weight 10. If there is a binary search tree built to test if n < 10, then its two out-edges will have weight 4x10+10/2 = 45 and 3x10 + 10/2 = 35 respectively (currently they are 40 and 30 without considering the default weight). Each distribution (which is 5 here) will be stored in each SwitchWorkListItem for further distribution. There are some exceptions: For a jump table header which doesn't have any edge to default statement, we don't distribute the default weight to it. For a bit test header which covers a contiguous range and hence has no edges to default statement, we don't distribute the default weight to it. When the branch checks a single value or a contiguous range with no edge to default statement, we don't distribute the default weight to it. In other cases, the default weight is evenly distributed to successors. Differential Revision: http://reviews.llvm.org/D12418 llvm-svn: 246522
2015-09-01 09:42:16 +08:00
; CHECK: je
Prevent binary-tree deterioration in sparse switch statements. This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
2015-01-21 03:43:33 +08:00
; CHECK: cmpl $60
; CHECK: jne
}