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/2010-11-01-lshr-mask.ll

47 lines
1.1 KiB
LLVM
Raw Normal View History

When folding away a (shl (shr)) pair, we need to check that the bits that will BECOME the low bits are zero, not that the current low bits are zero. Fixes <rdar://problem/8606771>. llvm-svn: 117953
2010-11-02 05:08:20 +08:00
; RUN: opt -instcombine -S < %s | FileCheck %s
Really check that the bits that will become zero are actually already zero before eliminating the operation that zeros them. This fixes rdar://8739316. llvm-svn: 121353
2010-12-09 10:52:17 +08:00
; <rdar://problem/8606771>
; CHECK: @main
When folding away a (shl (shr)) pair, we need to check that the bits that will BECOME the low bits are zero, not that the current low bits are zero. Fixes <rdar://problem/8606771>. llvm-svn: 117953
2010-11-02 05:08:20 +08:00
define i32 @main(i32 %argc) nounwind ssp {
entry:
%tmp3151 = trunc i32 %argc to i8
rdar://12329730 (2nd part) This change tries to simmplify E1 = " X >> C1 << C2" into : - E2 = "X << (C2 - C1)" if C2 > C1, or - E2 = "X >> (C1 - C2)" if C1 > C2, or - E2 = X if C1 == C2. Reviewed by Nadav. Thanks! llvm-svn: 169182
2012-12-04 08:04:54 +08:00
; CHECK: %tmp3162 = shl i8 %tmp3151, 5
; CHECK: and i8 %tmp3162, 64
Have SimplifyBinOp dispatch Xor, Add and Sub to the corresponding methods (they had just been forgotten before). Adding Xor causes "main" in the existing testcase 2010-11-01-lshr-mask.ll to be hugely more simplified. llvm-svn: 122245
2010-12-20 22:47:04 +08:00
; CHECK-NOT: shl
; CHECK-NOT: shr
When folding away a (shl (shr)) pair, we need to check that the bits that will BECOME the low bits are zero, not that the current low bits are zero. Fixes <rdar://problem/8606771>. llvm-svn: 117953
2010-11-02 05:08:20 +08:00
%tmp3161 = or i8 %tmp3151, -17
%tmp3162 = and i8 %tmp3151, 122
%tmp3163 = xor i8 %tmp3162, -17
%tmp4114 = shl i8 %tmp3163, 6
%tmp4115 = xor i8 %tmp4114, %tmp3163
%tmp4120 = xor i8 %tmp3161, %tmp4115
%tmp4126 = lshr i8 %tmp4120, 7
%tmp4127 = mul i8 %tmp4126, 64
%tmp4086 = zext i8 %tmp4127 to i32
; CHECK: ret i32
ret i32 %tmp4086
}
Really check that the bits that will become zero are actually already zero before eliminating the operation that zeros them. This fixes rdar://8739316. llvm-svn: 121353
2010-12-09 10:52:17 +08:00
; rdar://8739316
; CHECK: @foo
define i8 @foo(i8 %arg, i8 %arg1) nounwind {
bb:
%tmp = shl i8 %arg, 7
%tmp2 = and i8 %arg1, 84
%tmp3 = and i8 %arg1, -118
%tmp4 = and i8 %arg1, 33
%tmp5 = sub i8 -88, %tmp2
%tmp6 = and i8 %tmp5, 84
%tmp7 = or i8 %tmp4, %tmp6
%tmp8 = xor i8 %tmp, %tmp3
%tmp9 = or i8 %tmp7, %tmp8
%tmp10 = lshr i8 %tmp8, 7
%tmp11 = shl i8 %tmp10, 5
Reapply r155136 after fixing PR12599. Original commit message: Defer some shl transforms to DAGCombine. The shl instruction is used to represent multiplication by a constant power of two as well as bitwise left shifts. Some InstCombine transformations would turn an shl instruction into a bit mask operation, making it difficult for later analysis passes to recognize the constsnt multiplication. Disable those shl transformations, deferring them to DAGCombine time. An 'shl X, C' instruction is now treated mostly the same was as 'mul X, C'. These transformations are deferred: (X >>? C) << C --> X & (-1 << C) (When X >> C has multiple uses) (X >>? C1) << C2 --> X << (C2-C1) & (-1 << C2) (When C2 > C1) (X >>? C1) << C2 --> X >>? (C1-C2) & (-1 << C2) (When C1 > C2) The corresponding exact transformations are preserved, just like div-exact + mul: (X >>?,exact C) << C --> X (X >>?,exact C1) << C2 --> X << (C2-C1) (X >>?,exact C1) << C2 --> X >>?,exact (C1-C2) The disabled transformations could also prevent the instruction selector from recognizing rotate patterns in hash functions and cryptographic primitives. I have a test case for that, but it is too fragile. llvm-svn: 155362
2012-04-24 01:39:52 +08:00
; CHECK: %tmp10 = lshr i8 %tmp8, 7
; CHECK: %tmp11 = shl nuw nsw i8 %tmp10, 5
Really check that the bits that will become zero are actually already zero before eliminating the operation that zeros them. This fixes rdar://8739316. llvm-svn: 121353
2010-12-09 10:52:17 +08:00
%tmp12 = xor i8 %tmp11, %tmp9
ret i8 %tmp12
}