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/InstCombine/div-shift.ll

76 lines
1.8 KiB
LLVM
Raw Normal View History

Look pass zext to strength reduce an udiv. Patch by David Majnemer. rdar://11721329 llvm-svn: 158946
2012-06-22 06:52:49 +08:00
; RUN: opt < %s -instcombine -S | FileCheck %s
define i32 @t1(i16 zeroext %x, i32 %y) nounwind {
entry:
; CHECK: t1
; CHECK-NOT: sdiv
; CHECK: lshr i32 %conv
%conv = zext i16 %x to i32
%s = shl i32 2, %y
%d = sdiv i32 %conv, %s
ret i32 %d
}
; rdar://11721329
define i64 @t2(i64 %x, i32 %y) nounwind {
; CHECK: t2
; CHECK-NOT: udiv
; CHECK: lshr i64 %x
%1 = shl i32 1, %y
%2 = zext i32 %1 to i64
%3 = udiv i64 %x, %2
ret i64 %3
}
InstCombine: Make sure we use the pre-zext type when creating a constant of a value that is zext'd. Fixes PR13250. llvm-svn: 164377
2012-09-22 00:26:41 +08:00
; PR13250
define i64 @t3(i64 %x, i32 %y) nounwind {
; CHECK: t3
; CHECK-NOT: udiv
; CHECK-NEXT: %1 = add i32 %y, 2
; CHECK-NEXT: %2 = zext i32 %1 to i64
; CHECK-NEXT: %3 = lshr i64 %x, %2
; CHECK-NEXT: ret i64 %3
%1 = shl i32 4, %y
%2 = zext i32 %1 to i64
%3 = udiv i64 %x, %2
ret i64 %3
}
InstCombine: Be more agressive optimizing 'udiv' instrs with 'select' denoms Real world code sometimes has the denominator of a 'udiv' be a 'select'. LLVM can handle such cases but only when the 'select' operands are symmetric in structure (both select operands are a constant power of two or a left shift, etc.). This falls apart if we are dealt a 'udiv' where the code is not symetric or if the select operands lead us to more select instructions. Instead, we should treat the LHS and each select operand as a distinct divide operation and try to optimize them independently. If we can to simplify each operation, then we can replace the 'udiv' with, say, a 'lshr' that has a new select with a bunch of new operands for the select. llvm-svn: 185257
2013-06-29 16:40:07 +08:00
define i32 @t4(i32 %x, i32 %y) nounwind {
; CHECK: t4
; CHECK-NOT: udiv
; CHECK-NEXT: [[CMP:%.*]] = icmp ult i32 %y, 5
; CHECK-NEXT: [[SEL:%.*]] = select i1 [[CMP]], i32 5, i32 %y
; CHECK-NEXT: [[SHR:%.*]] = lshr i32 %x, [[SEL]]
; CHECK-NEXT: ret i32 [[SHR]]
%1 = shl i32 1, %y
%2 = icmp ult i32 %1, 32
%3 = select i1 %2, i32 32, i32 %1
%4 = udiv i32 %x, %3
ret i32 %4
}
define i32 @t5(i1 %x, i1 %y, i32 %V) nounwind {
; CHECK: t5
; CHECK-NOT: udiv
; CHECK-NEXT: [[SEL1:%.*]] = select i1 %x, i32 5, i32 6
InstSimplify: X >> X -> 0 llvm-svn: 185973
2013-07-10 06:01:22 +08:00
; CHECK-NEXT: [[LSHR:%.*]] = lshr i32 %V, [[SEL1]]
; CHECK-NEXT: [[SEL2:%.*]] = select i1 %y, i32 [[LSHR]], i32 0
; CHECK-NEXT: ret i32 [[SEL2]]
InstCombine: Be more agressive optimizing 'udiv' instrs with 'select' denoms Real world code sometimes has the denominator of a 'udiv' be a 'select'. LLVM can handle such cases but only when the 'select' operands are symmetric in structure (both select operands are a constant power of two or a left shift, etc.). This falls apart if we are dealt a 'udiv' where the code is not symetric or if the select operands lead us to more select instructions. Instead, we should treat the LHS and each select operand as a distinct divide operation and try to optimize them independently. If we can to simplify each operation, then we can replace the 'udiv' with, say, a 'lshr' that has a new select with a bunch of new operands for the select. llvm-svn: 185257
2013-06-29 16:40:07 +08:00
%1 = shl i32 1, %V
%2 = select i1 %x, i32 32, i32 64
%3 = select i1 %y, i32 %2, i32 %1
%4 = udiv i32 %V, %3
ret i32 %4
}
define i32 @t6(i32 %x, i32 %z) nounwind{
; CHECK: t6
; CHECK-NEXT: [[CMP:%.*]] = icmp eq i32 %x, 0
; CHECK-NOT: udiv i32 %z, %x
%x_is_zero = icmp eq i32 %x, 0
%divisor = select i1 %x_is_zero, i32 1, i32 %x
%y = udiv i32 %z, %divisor
ret i32 %y
}