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

86 lines
2.3 KiB
LLVM
Raw Normal View History

[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
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
[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
define i32 @t1(i16 zeroext %x, i32 %y) {
; CHECK-LABEL: @t1(
; CHECK-NEXT: entry:
; CHECK-NEXT: [[CONV:%.*]] = zext i16 %x to i32
; CHECK-NEXT: [[TMP0:%.*]] = add i32 %y, 1
; CHECK-NEXT: [[D:%.*]] = lshr i32 [[CONV]], [[TMP0]]
; CHECK-NEXT: ret i32 [[D]]
;
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
entry:
%conv = zext i16 %x to i32
%s = shl i32 2, %y
%d = sdiv i32 %conv, %s
ret i32 %d
}
; rdar://11721329
[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
define i64 @t2(i64 %x, i32 %y) {
; CHECK-LABEL: @t2(
; CHECK-NEXT: [[TMP1:%.*]] = zext i32 %y to i64
; CHECK-NEXT: [[TMP2:%.*]] = lshr i64 %x, [[TMP1]]
; CHECK-NEXT: ret i64 [[TMP2]]
;
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
%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
[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
define i64 @t3(i64 %x, i32 %y) {
; CHECK-LABEL: @t3(
; CHECK-NEXT: [[TMP1:%.*]] = add i32 %y, 2
; CHECK-NEXT: [[TMP2:%.*]] = zext i32 [[TMP1]] to i64
; CHECK-NEXT: [[TMP3:%.*]] = lshr i64 %x, [[TMP2]]
; CHECK-NEXT: ret i64 [[TMP3]]
;
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
%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
[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
define i32 @t4(i32 %x, i32 %y) {
; CHECK-LABEL: @t4(
[InstCombine] canonicalize min/max constant to select's false value This is a first step towards canonicalization and improved folding/codegen for integer min/max as discussed here: http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html Here, we're just matching the simplest min/max patterns and adjusting the icmp predicate while swapping the select operands. I've included FIXME tests in test/Transforms/InstCombine/select_meta.ll so it's easier to see how this might be extended (corresponds to the TODO comment in the code). That's also why I'm using matchSelectPattern() rather than a simpler check; once the backend is patched, we can just remove some of the restrictions to allow the obfuscated min/max patterns in the FIXME tests to be matched. Differential Revision: https://reviews.llvm.org/D26525 llvm-svn: 287585
2016-11-22 06:04:14 +08:00
; CHECK-NEXT: [[TMP1:%.*]] = icmp ugt i32 %y, 5
; CHECK-NEXT: [[DOTV:%.*]] = select i1 [[TMP1]], i32 %y, i32 5
[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
; CHECK-NEXT: [[TMP2:%.*]] = lshr i32 %x, [[DOTV]]
; CHECK-NEXT: ret i32 [[TMP2]]
;
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, %y
%2 = icmp ult i32 %1, 32
%3 = select i1 %2, i32 32, i32 %1
%4 = udiv i32 %x, %3
ret i32 %4
}
[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
define i32 @t5(i1 %x, i1 %y, i32 %V) {
; CHECK-LABEL: @t5(
; CHECK-NEXT: [[DOTV:%.*]] = select i1 %x, i32 5, i32 6
; CHECK-NEXT: [[TMP1:%.*]] = lshr i32 %V, [[DOTV]]
; CHECK-NEXT: [[TMP2:%.*]] = select i1 %y, i32 [[TMP1]], i32 0
; CHECK-NEXT: ret i32 [[TMP2]]
;
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
}
[InstCombine] regenerate checks llvm-svn: 268239
2016-05-02 23:06:55 +08:00
define i32 @t6(i32 %x, i32 %z) {
; CHECK-LABEL: @t6(
; CHECK-NEXT: [[X_IS_ZERO:%.*]] = icmp eq i32 %x, 0
; CHECK-NEXT: [[DIVISOR:%.*]] = select i1 [[X_IS_ZERO]], i32 1, i32 %x
; CHECK-NEXT: [[Y:%.*]] = udiv i32 %z, [[DIVISOR]]
; CHECK-NEXT: ret i32 [[Y]]
;
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
%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
}