We visit and/or, we try to derive a lattice value for the instruction even if one of the operands is overdefined. If the non-overdefined value is still 'unknown' just return and wait for ResolvedUndefsIn to "plug in" the correct value. This simplifies the logic a bit. While I'm here add tests for missing cases. llvm-svn: 287709
32 lines
546 B
LLVM
32 lines
546 B
LLVM
; RUN: opt < %s -sccp -S | FileCheck %s
|
|
|
|
; Test that SCCP has basic knowledge of when and/or nuke overdefined values.
|
|
|
|
; CHECK-LABEL: test
|
|
; CHECK: ret i32 0
|
|
define i32 @test(i32 %X) {
|
|
%Y = and i32 %X, 0
|
|
ret i32 %Y
|
|
}
|
|
|
|
; CHECK-LABEL: test2
|
|
; CHECK: ret i32 -1
|
|
define i32 @test2(i32 %X) {
|
|
%Y = or i32 -1, %X
|
|
ret i32 %Y
|
|
}
|
|
|
|
; CHECK-LABEL: test3
|
|
; CHECK: ret i32 0
|
|
define i32 @test3(i32 %X) {
|
|
%Y = and i32 undef, %X
|
|
ret i32 %Y
|
|
}
|
|
|
|
; CHECK-LABEL: test4
|
|
; CHECK: ret i32 -1
|
|
define i32 @test4(i32 %X) {
|
|
%Y = or i32 %X, undef
|
|
ret i32 %Y
|
|
}
|