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/and2.ll

251 lines
7.3 KiB
LLVM
Raw Normal View History

[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
convert to filecheck. llvm-svn: 95854
2010-02-11 14:24:37 +08:00
; RUN: opt < %s -instcombine -S | FileCheck %s
Implement a couple of foldings for ordered and unordered comparisons, implementing cases related to PR1738. llvm-svn: 43289
2007-10-24 13:38:08 +08:00
Teach InstructionSimplify to fold (A & B) & A -> A & B and (A | B) | A -> A | B. Reassociate does this but it doesn't catch all cases (e.g. if the operands are i1). llvm-svn: 113651
2010-09-11 06:39:55 +08:00
define i1 @test2(i1 %X, i1 %Y) {
[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; CHECK-LABEL: @test2(
; CHECK-NEXT: [[B:%.*]] = and i1 %X, %Y
; CHECK-NEXT: ret i1 [[B]]
;
Teach InstructionSimplify to fold (A & B) & A -> A & B and (A | B) | A -> A | B. Reassociate does this but it doesn't catch all cases (e.g. if the operands are i1). llvm-svn: 113651
2010-09-11 06:39:55 +08:00
%a = and i1 %X, %Y
%b = and i1 %a, %X
ret i1 %b
}
define i32 @test3(i32 %X, i32 %Y) {
[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; CHECK-LABEL: @test3(
; CHECK-NEXT: [[B:%.*]] = and i32 %X, %Y
; CHECK-NEXT: ret i32 [[B]]
;
Teach InstructionSimplify to fold (A & B) & A -> A & B and (A | B) | A -> A | B. Reassociate does this but it doesn't catch all cases (e.g. if the operands are i1). llvm-svn: 113651
2010-09-11 06:39:55 +08:00
%a = and i32 %X, %Y
%b = and i32 %Y, %a
ret i32 %b
}
Make InstCombiner::FoldAndOfICmps create a ConstantRange that's the intersection of the LHS and RHS ConstantRanges and return "false" when the range is empty. This simplifies some code and catches some extra cases. llvm-svn: 126744
2011-03-01 23:05:01 +08:00
Fix an infinite loop where a transform in InstCombiner::visitAnd claims a construct is changed when it is not. (See included testcase.) Patch by Xiaoyi Guo. llvm-svn: 140072
2011-09-20 05:58:15 +08:00
; Make sure we don't go into an infinite loop with this test
define <4 x i32> @test5(<4 x i32> %A) {
[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; CHECK-LABEL: @test5(
; CHECK-NEXT: [[TMP1:%.*]] = xor <4 x i32> %A, <i32 1, i32 2, i32 3, i32 4>
; CHECK-NEXT: [[TMP2:%.*]] = and <4 x i32> [[TMP1]], <i32 1, i32 2, i32 3, i32 4>
; CHECK-NEXT: ret <4 x i32> [[TMP2]]
;
Fix an infinite loop where a transform in InstCombiner::visitAnd claims a construct is changed when it is not. (See included testcase.) Patch by Xiaoyi Guo. llvm-svn: 140072
2011-09-20 05:58:15 +08:00
%1 = xor <4 x i32> %A, <i32 1, i32 2, i32 3, i32 4>
%2 = and <4 x i32> <i32 1, i32 2, i32 3, i32 4>, %1
ret <4 x i32> %2
}
InstCombine: Simplify if(x!=0 && x!=-1). When both constants are positive or both constants are negative, InstCombine already simplifies comparisons like this, but when it's exactly zero and -1, the operand sorting ends up reversed and the pattern fails to match. Handle that special case. Follow up for rdar://14689217 llvm-svn: 188512
2013-08-16 08:15:20 +08:00
InstCombine: Try harder to combine icmp instructions consider: (and (icmp X, Y), (and Z, (icmp A, B))) It may be possible to combine (icmp X, Y) with (icmp A, B). If we successfully combine, create an 'and' instruction with Z. This fixes PR20814. N.B. There is room for improvement after this change but I'm not convinced it's worth chasing yet. llvm-svn: 216814
2014-08-30 14:18:20 +08:00
define i1 @test7(i32 %i, i1 %b) {
; CHECK-LABEL: @test7(
[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; CHECK-NEXT: [[TMP1:%.*]] = icmp eq i32 %i, 0
; CHECK-NEXT: [[TMP2:%.*]] = and i1 [[TMP1]], %b
; CHECK-NEXT: ret i1 [[TMP2]]
;
InstCombine: Try harder to combine icmp instructions consider: (and (icmp X, Y), (and Z, (icmp A, B))) It may be possible to combine (icmp X, Y) with (icmp A, B). If we successfully combine, create an 'and' instruction with Z. This fixes PR20814. N.B. There is room for improvement after this change but I'm not convinced it's worth chasing yet. llvm-svn: 216814
2014-08-30 14:18:20 +08:00
%cmp1 = icmp slt i32 %i, 1
%cmp2 = icmp sgt i32 %i, -1
%and1 = and i1 %cmp1, %b
%and2 = and i1 %and1, %cmp2
ret i1 %and2
}
InstCombine: Turn (x != 0 & x <u C) into the canonical range check form (x-1 <u C-1) llvm-svn: 219585
2014-10-12 22:02:34 +08:00
define i1 @test8(i32 %i) {
; CHECK-LABEL: @test8(
[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; CHECK-NEXT: [[I_OFF:%.*]] = add i32 %i, -1
; CHECK-NEXT: [[TMP1:%.*]] = icmp ult i32 [[I_OFF]], 13
; CHECK-NEXT: ret i1 [[TMP1]]
;
InstCombine: Turn (x != 0 & x <u C) into the canonical range check form (x-1 <u C-1) llvm-svn: 219585
2014-10-12 22:02:34 +08:00
%cmp1 = icmp ne i32 %i, 0
%cmp2 = icmp ult i32 %i, 14
%cond = and i1 %cmp1, %cmp2
ret i1 %cond
}
Optimize bitwise even/odd test (-x&1 -> x&1) to not use negation. Summary: We know that -x & 1 is equivalent to x & 1, avoid using negation for testing if a negative integer is even or odd. Reviewers: majnemer Subscribers: junbuml, mssimpso, gberry, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D12156 llvm-svn: 245569
2015-08-20 23:35:00 +08:00
[InstCombine] add tests to show type limitations of InsertRangeTest and callers llvm-svn: 280175
2016-08-31 07:16:59 +08:00
; FIXME: Vectors should fold too.
define <2 x i1> @test8vec(<2 x i32> %i) {
; CHECK-LABEL: @test8vec(
; CHECK-NEXT: [[CMP1:%.*]] = icmp ne <2 x i32> %i, zeroinitializer
; CHECK-NEXT: [[CMP2:%.*]] = icmp ult <2 x i32> %i, <i32 14, i32 14>
; CHECK-NEXT: [[COND:%.*]] = and <2 x i1> [[CMP1]], [[CMP2]]
; CHECK-NEXT: ret <2 x i1> [[COND]]
;
%cmp1 = icmp ne <2 x i32> %i, zeroinitializer
%cmp2 = icmp ult <2 x i32> %i, <i32 14, i32 14>
%cond = and <2 x i1> %cmp1, %cmp2
ret <2 x i1> %cond
}
Optimize bitwise even/odd test (-x&1 -> x&1) to not use negation. Summary: We know that -x & 1 is equivalent to x & 1, avoid using negation for testing if a negative integer is even or odd. Reviewers: majnemer Subscribers: junbuml, mssimpso, gberry, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D12156 llvm-svn: 245569
2015-08-20 23:35:00 +08:00
; combine -x & 1 into x & 1
define i64 @test9(i64 %x) {
; CHECK-LABEL: @test9(
[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; CHECK-NEXT: [[AND:%.*]] = and i64 %x, 1
; CHECK-NEXT: ret i64 [[AND]]
;
Optimize bitwise even/odd test (-x&1 -> x&1) to not use negation. Summary: We know that -x & 1 is equivalent to x & 1, avoid using negation for testing if a negative integer is even or odd. Reviewers: majnemer Subscribers: junbuml, mssimpso, gberry, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D12156 llvm-svn: 245569
2015-08-20 23:35:00 +08:00
%sub = sub nsw i64 0, %x
%and = and i64 %sub, 1
ret i64 %and
}
[InstCombine] Add vector version of a test to show missing optimization. llvm-svn: 300161
2017-04-13 09:31:40 +08:00
; combine -x & 1 into x & 1
define <2 x i64> @test9vec(<2 x i64> %x) {
; CHECK-LABEL: @test9vec(
[InstCombine] allow (0 - x) & 1 --> x & 1 for vectors llvm-svn: 308098
2017-07-15 23:29:47 +08:00
; CHECK-NEXT: [[AND:%.*]] = and <2 x i64> %x, <i64 1, i64 1>
[InstCombine] Add vector version of a test to show missing optimization. llvm-svn: 300161
2017-04-13 09:31:40 +08:00
; CHECK-NEXT: ret <2 x i64> [[AND]]
;
%sub = sub nsw <2 x i64> <i64 0, i64 0>, %x
%and = and <2 x i64> %sub, <i64 1, i64 1>
ret <2 x i64> %and
}
Optimize bitwise even/odd test (-x&1 -> x&1) to not use negation. Summary: We know that -x & 1 is equivalent to x & 1, avoid using negation for testing if a negative integer is even or odd. Reviewers: majnemer Subscribers: junbuml, mssimpso, gberry, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D12156 llvm-svn: 245569
2015-08-20 23:35:00 +08:00
define i64 @test10(i64 %x) {
; CHECK-LABEL: @test10(
[InstCombine] regenerate checks llvm-svn: 273170
2016-06-21 01:48:48 +08:00
; CHECK-NEXT: [[AND:%.*]] = and i64 %x, 1
; CHECK-NEXT: [[ADD:%.*]] = sub i64 [[AND]], %x
; CHECK-NEXT: ret i64 [[ADD]]
;
Optimize bitwise even/odd test (-x&1 -> x&1) to not use negation. Summary: We know that -x & 1 is equivalent to x & 1, avoid using negation for testing if a negative integer is even or odd. Reviewers: majnemer Subscribers: junbuml, mssimpso, gberry, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D12156 llvm-svn: 245569
2015-08-20 23:35:00 +08:00
%sub = sub nsw i64 0, %x
%and = and i64 %sub, 1
%add = add i64 %sub, %and
ret i64 %add
}
[InstCombine] transform masking off of an FP sign bit into a fabs() intrinsic call (PR24886) This is a partial fix for PR24886: https://llvm.org/bugs/show_bug.cgi?id=24886 Without this IR transform, the backend (x86 at least) was producing inefficient code. This patch is making 2 assumptions: 1. The canonical form of a fabs() operation is, in fact, the LLVM fabs() intrinsic. 2. The high bit of an FP value is always the sign bit; as noted in the bug report, this isn't specified by the LangRef. Differential Revision: http://reviews.llvm.org/D13076 llvm-svn: 249702
2015-10-09 01:09:31 +08:00
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; (1 << x) & 1 --> zext(x == 0)
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
define i8 @and1_shl1_is_cmp_eq_0(i8 %x) {
; CHECK-LABEL: @and1_shl1_is_cmp_eq_0(
; CHECK-NEXT: [[TMP1:%.*]] = icmp eq i8 %x, 0
; CHECK-NEXT: [[AND:%.*]] = zext i1 [[TMP1]] to i8
; CHECK-NEXT: ret i8 [[AND]]
;
%sh = shl i8 1, %x
%and = and i8 %sh, 1
ret i8 %and
}
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; Don't do it if the shift has another use.
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
define i8 @and1_shl1_is_cmp_eq_0_multiuse(i8 %x) {
; CHECK-LABEL: @and1_shl1_is_cmp_eq_0_multiuse(
; CHECK-NEXT: [[SH:%.*]] = shl i8 1, %x
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; CHECK-NEXT: [[AND:%.*]] = and i8 [[SH]], 1
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
; CHECK-NEXT: [[ADD:%.*]] = add i8 [[SH]], [[AND]]
; CHECK-NEXT: ret i8 [[ADD]]
;
%sh = shl i8 1, %x
%and = and i8 %sh, 1
%add = add i8 %sh, %and
ret i8 %add
}
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; (1 << x) & 1 --> zext(x == 0)
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
define <2 x i8> @and1_shl1_is_cmp_eq_0_vec(<2 x i8> %x) {
; CHECK-LABEL: @and1_shl1_is_cmp_eq_0_vec(
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; CHECK-NEXT: [[TMP1:%.*]] = icmp eq <2 x i8> %x, zeroinitializer
; CHECK-NEXT: [[AND:%.*]] = zext <2 x i1> [[TMP1]] to <2 x i8>
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
; CHECK-NEXT: ret <2 x i8> [[AND]]
;
%sh = shl <2 x i8> <i8 1, i8 1>, %x
%and = and <2 x i8> %sh, <i8 1, i8 1>
ret <2 x i8> %and
}
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; (1 >> x) & 1 --> zext(x == 0)
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
define i8 @and1_lshr1_is_cmp_eq_0(i8 %x) {
; CHECK-LABEL: @and1_lshr1_is_cmp_eq_0(
; CHECK-NEXT: [[TMP1:%.*]] = icmp eq i8 %x, 0
; CHECK-NEXT: [[AND:%.*]] = zext i1 [[TMP1]] to i8
; CHECK-NEXT: ret i8 [[AND]]
;
%sh = lshr i8 1, %x
%and = and i8 %sh, 1
ret i8 %and
}
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; Don't do it if the shift has another use.
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
define i8 @and1_lshr1_is_cmp_eq_0_multiuse(i8 %x) {
; CHECK-LABEL: @and1_lshr1_is_cmp_eq_0_multiuse(
; CHECK-NEXT: [[SH:%.*]] = lshr i8 1, %x
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; CHECK-NEXT: [[AND:%.*]] = and i8 [[SH]], 1
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
; CHECK-NEXT: [[ADD:%.*]] = add i8 [[SH]], [[AND]]
; CHECK-NEXT: ret i8 [[ADD]]
;
%sh = lshr i8 1, %x
%and = and i8 %sh, 1
%add = add i8 %sh, %and
ret i8 %add
}
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; (1 >> x) & 1 --> zext(x == 0)
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
define <2 x i8> @and1_lshr1_is_cmp_eq_0_vec(<2 x i8> %x) {
; CHECK-LABEL: @and1_lshr1_is_cmp_eq_0_vec(
[InstCombine] improve (1 << x) & 1 --> zext(x == 0) folding 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
2017-07-16 01:26:01 +08:00
; CHECK-NEXT: [[TMP1:%.*]] = icmp eq <2 x i8> %x, zeroinitializer
; CHECK-NEXT: [[AND:%.*]] = zext <2 x i1> [[TMP1]] to <2 x i8>
[InstCombine] add tests for (1 << x) & 1 --> zext(x == 0) ; NFC This fold hit the trifecta: 1. It was untested. 2. It oversteps (multiuse is not checked, so increases instruction count). 3. It is incomplete (doesn't work for vectors). llvm-svn: 308102
2017-07-15 23:55:07 +08:00
; CHECK-NEXT: ret <2 x i8> [[AND]]
;
%sh = lshr <2 x i8> <i8 1, i8 1>, %x
%and = and <2 x i8> %sh, <i8 1, i8 1>
ret <2 x i8> %and
}
Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation. My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran. With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything. Differential Revision: https://reviews.llvm.org/D31120 llvm-svn: 300075
2017-04-13 00:49:59 +08:00
; The add in this test is unnecessary because the LSBs of the LHS are 0 and the 'and' only consumes bits from those LSBs. It doesn't matter what happens to the upper bits.
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
define i32 @test11(i32 %a, i32 %b) {
; CHECK-LABEL: @test11(
; CHECK-NEXT: [[X:%.*]] = shl i32 [[A:%.*]], 8
Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation. My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran. With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything. Differential Revision: https://reviews.llvm.org/D31120 llvm-svn: 300075
2017-04-13 00:49:59 +08:00
; CHECK-NEXT: [[Z:%.*]] = and i32 [[B:%.*]], 128
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
; CHECK-NEXT: [[W:%.*]] = mul i32 [[Z]], [[X]]
; CHECK-NEXT: ret i32 [[W]]
;
%x = shl i32 %a, 8
%y = add i32 %x, %b
%z = and i32 %y, 128
%w = mul i32 %z, %x ; to keep the shift from being removed
ret i32 %w
}
Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation. My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran. With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything. Differential Revision: https://reviews.llvm.org/D31120 llvm-svn: 300075
2017-04-13 00:49:59 +08:00
; The add in this test is unnecessary because the LSBs of the RHS are 0 and the 'and' only consumes bits from those LSBs. It doesn't matter what happens to the upper bits.
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
define i32 @test12(i32 %a, i32 %b) {
; CHECK-LABEL: @test12(
; CHECK-NEXT: [[X:%.*]] = shl i32 [[A:%.*]], 8
Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation. My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran. With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything. Differential Revision: https://reviews.llvm.org/D31120 llvm-svn: 300075
2017-04-13 00:49:59 +08:00
; CHECK-NEXT: [[Z:%.*]] = and i32 [[B:%.*]], 128
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
; CHECK-NEXT: [[W:%.*]] = mul i32 [[Z]], [[X]]
; CHECK-NEXT: ret i32 [[W]]
;
%x = shl i32 %a, 8
%y = add i32 %b, %x
%z = and i32 %y, 128
%w = mul i32 %z, %x ; to keep the shift from being removed
ret i32 %w
}
Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation. My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran. With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything. Differential Revision: https://reviews.llvm.org/D31120 llvm-svn: 300075
2017-04-13 00:49:59 +08:00
; The sub in this test is unnecessary because the LSBs of the RHS are 0 and the 'and' only consumes bits from those LSBs. It doesn't matter what happens to the upper bits.
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
define i32 @test13(i32 %a, i32 %b) {
; CHECK-LABEL: @test13(
; CHECK-NEXT: [[X:%.*]] = shl i32 [[A:%.*]], 8
Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation. My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran. With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything. Differential Revision: https://reviews.llvm.org/D31120 llvm-svn: 300075
2017-04-13 00:49:59 +08:00
; CHECK-NEXT: [[Z:%.*]] = and i32 [[B:%.*]], 128
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
; CHECK-NEXT: [[W:%.*]] = mul i32 [[Z]], [[X]]
; CHECK-NEXT: ret i32 [[W]]
;
%x = shl i32 %a, 8
%y = sub i32 %b, %x
%z = and i32 %y, 128
%w = mul i32 %z, %x ; to keep the shift from being removed
ret i32 %w
}
Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation. My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran. With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything. Differential Revision: https://reviews.llvm.org/D31120 llvm-svn: 300075
2017-04-13 00:49:59 +08:00
; The sub in this test cannot be removed because we need to keep the negation of %b. TODO: But we should be able to replace the LHS of it with a 0.
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
define i32 @test14(i32 %a, i32 %b) {
; CHECK-LABEL: @test14(
; CHECK-NEXT: [[X:%.*]] = shl i32 [[A:%.*]], 8
[InstCombine] Teach SimplifyDemandedInstructionBits that even if we reach an instruction that has multiple uses, if we know all the bits for the demanded bits for this context we can go ahead and create a constant. Currently if we reach an instruction with multiples uses we know we can't do any optimizations to that instruction itself since we only have the demanded bits for one of the users. But if we know all of the bits are zero/one for that one user we can still go ahead and create a constant to give to that user. This might then reduce the instruction to having a single use and allow additional optimizations on the other path. This picks up an additional case that r300075 didn't catch. Differential Revision: https://reviews.llvm.org/D31552 llvm-svn: 300084
2017-04-13 02:17:46 +08:00
; CHECK-NEXT: [[Y:%.*]] = sub i32 0, [[B:%.*]]
[InstCombine] Add test case demonstrating missed opportunities for removing add/sub when the LSBs of one input are known to be 0 and MSBs of the output aren't consumed. llvm-svn: 299263
2017-04-01 05:08:37 +08:00
; CHECK-NEXT: [[Z:%.*]] = and i32 [[Y]], 128
; CHECK-NEXT: [[W:%.*]] = mul i32 [[Z]], [[X]]
; CHECK-NEXT: ret i32 [[W]]
;
%x = shl i32 %a, 8
%y = sub i32 %x, %b
%z = and i32 %y, 128
%w = mul i32 %z, %x ; to keep the shift from being removed
ret i32 %w
}