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

65 lines
1.5 KiB
LLVM
Raw Normal View History

LazyValueInfo: Actually re-visit partially solved block-values in solveBlockValue() If solveBlockValue() needs results from predecessors that are not already computed, it returns false with the intention of resuming when the dependencies have been resolved. However, the computation would never be resumed since an 'overdefined' result had been placed in the cache, preventing any further computation. The point of placing the 'overdefined' result in the cache seems to have been to break cycles, but we can check for that when inserting work items in the BlockValue stack instead. This makes the "stop and resume" mechanism of solveBlockValue() work as intended, unlocking more analysis. Using this patch shaves 120 KB off a 64-bit Chromium build on Linux. I benchmarked compiling bzip2.c at -O2 but couldn't measure any difference in compile time. Tests by Jiangning Liu from r215343 / PR21238, Pete Cooper, and me. Differential Revision: http://reviews.llvm.org/D6397 llvm-svn: 222768
2014-11-26 01:23:05 +08:00
; RUN: opt -correlated-propagation -S %s | FileCheck %s
[PM] Port CorrelatedValuePropagation llvm-svn: 274705
2016-07-07 07:26:29 +08:00
; RUN: opt -passes=correlated-propagation -S %s | FileCheck %s
LazyValueInfo: Actually re-visit partially solved block-values in solveBlockValue() If solveBlockValue() needs results from predecessors that are not already computed, it returns false with the intention of resuming when the dependencies have been resolved. However, the computation would never be resumed since an 'overdefined' result had been placed in the cache, preventing any further computation. The point of placing the 'overdefined' result in the cache seems to have been to break cycles, but we can check for that when inserting work items in the BlockValue stack instead. This makes the "stop and resume" mechanism of solveBlockValue() work as intended, unlocking more analysis. Using this patch shaves 120 KB off a 64-bit Chromium build on Linux. I benchmarked compiling bzip2.c at -O2 but couldn't measure any difference in compile time. Tests by Jiangning Liu from r215343 / PR21238, Pete Cooper, and me. Differential Revision: http://reviews.llvm.org/D6397 llvm-svn: 222768
2014-11-26 01:23:05 +08:00
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.10.0"
; Function Attrs: noreturn
declare void @check1(i1) #1
; Function Attrs: noreturn
declare void @check2(i1) #1
; Make sure we propagate the value of %tmp35 to the true/false cases
; CHECK-LABEL: @test1
; CHECK: call void @check1(i1 false)
; CHECK: call void @check2(i1 true)
define void @test1(i64 %tmp35) {
bb:
%tmp36 = icmp sgt i64 %tmp35, 0
br i1 %tmp36, label %bb_true, label %bb_false
bb_true:
%tmp47 = icmp slt i64 %tmp35, 0
tail call void @check1(i1 %tmp47) #4
unreachable
bb_false:
%tmp48 = icmp sle i64 %tmp35, 0
tail call void @check2(i1 %tmp48) #4
unreachable
}
; Function Attrs: noreturn
; This is the same as test1 but with a diamond to ensure we
; get %tmp36 from both true and false BBs.
; CHECK-LABEL: @test2
; CHECK: call void @check1(i1 false)
; CHECK: call void @check2(i1 true)
define void @test2(i64 %tmp35, i1 %inner_cmp) {
bb:
%tmp36 = icmp sgt i64 %tmp35, 0
br i1 %tmp36, label %bb_true, label %bb_false
bb_true:
br i1 %inner_cmp, label %inner_true, label %inner_false
inner_true:
br label %merge
inner_false:
br label %merge
merge:
%tmp47 = icmp slt i64 %tmp35, 0
tail call void @check1(i1 %tmp47) #0
unreachable
bb_false:
%tmp48 = icmp sle i64 %tmp35, 0
tail call void @check2(i1 %tmp48) #4
unreachable
}
attributes #4 = { noreturn }