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/licm-dominance.ll

56 lines
1.6 KiB
LLVM
Raw Normal View History

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
; RUN: llc -asm-verbose=true < %s | FileCheck %s
Add dominance check for the instruction being hoisted. For example, MachineLICM should not hoist a load that is not guaranteed to be executed. Radar 10254254. llvm-svn: 141689
2011-10-12 02:09:58 +08:00
; MachineLICM should check dominance before hoisting instructions.
Codegen: LICM Remove check for exactly 1 register def. When considering whether to split an instruction with a memory operand into an explicit load and a register-based instruction, we currently check that the resulting instruction has exactly 1 def. This prevents 2 important LICM optimizations: compares with memory operands, and double indirect calls. All the tests and the test-suite pass without the check. My guess as to original intent is to limit the additional register pressure created by the new instruction, but given that we only split out a single register, it is already limited. The licm-dominance test now checks actual memory loads for hoisting instead of undef, and it tests compares. hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus from calling a got-relative function in a loop. llvm-svn: 273616
2016-06-24 05:38:49 +08:00
; only the load of a0 is guaranteed to execute, so only it can be hoisted.
; CHECK: movb (%rdi), [[a0reg:%[a-z0-9]+]]
; CHECK: ## %for.body.i
; CHECK: testb [[a0reg]], [[a0reg]]
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: ## in Loop:
Codegen: LICM Remove check for exactly 1 register def. When considering whether to split an instruction with a memory operand into an explicit load and a register-based instruction, we currently check that the resulting instruction has exactly 1 def. This prevents 2 important LICM optimizations: compares with memory operands, and double indirect calls. All the tests and the test-suite pass without the check. My guess as to original intent is to limit the additional register pressure created by the new instruction, but given that we only split out a single register, it is already limited. The licm-dominance test now checks actual memory loads for hoisting instead of undef, and it tests compares. hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus from calling a got-relative function in a loop. llvm-svn: 273616
2016-06-24 05:38:49 +08:00
; CHECK: cmpb $1, ({{%[a-z0-9]+}})
; CHECK: cmpb $2, ({{%[a-z0-9]+}})
; CHECK: cmpb $3, ({{%[a-z0-9]+}})
Add dominance check for the instruction being hoisted. For example, MachineLICM should not hoist a load that is not guaranteed to be executed. Radar 10254254. llvm-svn: 141689
2011-10-12 02:09:58 +08:00
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-apple-macosx10.7.2"
Codegen: LICM Remove check for exactly 1 register def. When considering whether to split an instruction with a memory operand into an explicit load and a register-based instruction, we currently check that the resulting instruction has exactly 1 def. This prevents 2 important LICM optimizations: compares with memory operands, and double indirect calls. All the tests and the test-suite pass without the check. My guess as to original intent is to limit the additional register pressure created by the new instruction, but given that we only split out a single register, it is already limited. The licm-dominance test now checks actual memory loads for hoisting instead of undef, and it tests compares. hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus from calling a got-relative function in a loop. llvm-svn: 273616
2016-06-24 05:38:49 +08:00
define void @CMSColorWorldCreateParametricData(
i8* dereferenceable(1) %a0,
i8* dereferenceable(1) %a1,
i8* dereferenceable(1) %a2,
i8* dereferenceable(1) %a3,
i64 %count) nounwind uwtable optsize ssp readonly {
Add dominance check for the instruction being hoisted. For example, MachineLICM should not hoist a load that is not guaranteed to be executed. Radar 10254254. llvm-svn: 141689
2011-10-12 02:09:58 +08:00
entry:
br label %for.body.i
Codegen: LICM Remove check for exactly 1 register def. When considering whether to split an instruction with a memory operand into an explicit load and a register-based instruction, we currently check that the resulting instruction has exactly 1 def. This prevents 2 important LICM optimizations: compares with memory operands, and double indirect calls. All the tests and the test-suite pass without the check. My guess as to original intent is to limit the additional register pressure created by the new instruction, but given that we only split out a single register, it is already limited. The licm-dominance test now checks actual memory loads for hoisting instead of undef, and it tests compares. hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus from calling a got-relative function in a loop. llvm-svn: 273616
2016-06-24 05:38:49 +08:00
for.body.i:
%i = phi i64 [0, %entry], [%i.inc, %for.inc.i]
%0 = load i8, i8* %a0, !invariant.load !0
%cond0 = icmp eq i8 %0, 0
br i1 %cond0, label %for.inc.i, label %if.then26.i
if.then26.i:
%1 = load i8, i8* %a1, !invariant.load !0
%cond1 = icmp eq i8 %1, 1
br i1 %cond1, label %if.else.i.i, label %lor.lhs.false.i.i
if.else.i.i:
%2 = load i8, i8* %a2, !invariant.load !0
%cond2 = icmp eq i8 %2, 2
br i1 %cond2, label %lor.lhs.false.i.i, label %for.inc.i
lor.lhs.false.i.i:
%3 = load i8, i8* %a3, !invariant.load !0
%cond3 = icmp eq i8 %3, 3
br i1 %cond3, label %for.inc.i, label %if.end28.i
for.inc.i:
%i.inc = add nsw i64 %i, 1
%cmp17.i = icmp ult i64 %i.inc, %count
Add dominance check for the instruction being hoisted. For example, MachineLICM should not hoist a load that is not guaranteed to be executed. Radar 10254254. llvm-svn: 141689
2011-10-12 02:09:58 +08:00
br i1 %cmp17.i, label %for.body.i, label %if.end28.i
Codegen: LICM Remove check for exactly 1 register def. When considering whether to split an instruction with a memory operand into an explicit load and a register-based instruction, we currently check that the resulting instruction has exactly 1 def. This prevents 2 important LICM optimizations: compares with memory operands, and double indirect calls. All the tests and the test-suite pass without the check. My guess as to original intent is to limit the additional register pressure created by the new instruction, but given that we only split out a single register, it is already limited. The licm-dominance test now checks actual memory loads for hoisting instead of undef, and it tests compares. hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus from calling a got-relative function in a loop. llvm-svn: 273616
2016-06-24 05:38:49 +08:00
if.end28.i:
Add dominance check for the instruction being hoisted. For example, MachineLICM should not hoist a load that is not guaranteed to be executed. Radar 10254254. llvm-svn: 141689
2011-10-12 02:09:58 +08:00
ret void
}
Codegen: LICM Remove check for exactly 1 register def. When considering whether to split an instruction with a memory operand into an explicit load and a register-based instruction, we currently check that the resulting instruction has exactly 1 def. This prevents 2 important LICM optimizations: compares with memory operands, and double indirect calls. All the tests and the test-suite pass without the check. My guess as to original intent is to limit the additional register pressure created by the new instruction, but given that we only split out a single register, it is already limited. The licm-dominance test now checks actual memory loads for hoisting instead of undef, and it tests compares. hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus from calling a got-relative function in a loop. llvm-svn: 273616
2016-06-24 05:38:49 +08:00
!0 = !{}