maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/lzcnt.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

200 lines
4.9 KiB
LLVM
Raw Normal View History

[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[CodeGen][X86] Remove unused trivial check-prefixes from all CodeGen/X86 directory. I had manually removed unused prefixes from CodeGen/X86 directory for more than 100 tests. I checked the change history for each of them at the beginning, and then I mainly focused on the format since I found all of the unused prefixes were result from either insensible copy or residuum after functional update. I think it's OK to remove the remaining X86 tests by script now. I wrote a rough script which works for me in most tests. I put it in llvm/utils temporarily for review and hope it may help other components owners. The tests in this patch are all generated by the tool and checked by update tool for the autogenerated tests. I skimmed them and checked about 30 tests and didn't find any unexpected changes. Reviewed By: mtrofin, MaskRay Differential Revision: https://reviews.llvm.org/D91496
2020-11-16 09:44:06 +08:00
; RUN: llc < %s -mtriple=i686-- -mattr=+lzcnt | FileCheck %s --check-prefix=X86
; RUN: llc < %s -mtriple=x86_64-linux-gnux32 -mattr=+lzcnt | FileCheck %s --check-prefix=X32
; RUN: llc < %s -mtriple=x86_64-- -mattr=+lzcnt | FileCheck %s --check-prefix=X64
Test case for X86 LZCNT instruction selection. llvm-svn: 141652
2011-10-11 14:47:01 +08:00
Cleanup this test a bit, sorting things and grouping them more clearly. llvm-svn: 147243
2011-12-24 18:55:42 +08:00
declare i8 @llvm.ctlz.i8(i8, i1) nounwind readnone
declare i16 @llvm.ctlz.i16(i16, i1) nounwind readnone
declare i32 @llvm.ctlz.i32(i32, i1) nounwind readnone
declare i64 @llvm.ctlz.i64(i64, i1) nounwind readnone
define i8 @t1(i8 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t1:
; X86: # %bb.0:
; X86-NEXT: movzbl {{[0-9]+}}(%esp), %eax
; X86-NEXT: lzcntl %eax, %eax
; X86-NEXT: addl $-24, %eax
; X86-NEXT: # kill: def $al killed $al killed $eax
; X86-NEXT: retl
;
; X32-LABEL: t1:
; X32: # %bb.0:
; X32-NEXT: movzbl %dil, %eax
; X32-NEXT: lzcntl %eax, %eax
; X32-NEXT: addl $-24, %eax
; X32-NEXT: # kill: def $al killed $al killed $eax
; X32-NEXT: retq
;
; X64-LABEL: t1:
; X64: # %bb.0:
; X64-NEXT: movzbl %dil, %eax
; X64-NEXT: lzcntl %eax, %eax
; X64-NEXT: addl $-24, %eax
; X64-NEXT: # kill: def $al killed $al killed $eax
; X64-NEXT: retq
Cleanup this test a bit, sorting things and grouping them more clearly. llvm-svn: 147243
2011-12-24 18:55:42 +08:00
%tmp = tail call i8 @llvm.ctlz.i8( i8 %x, i1 false )
ret i8 %tmp
Test case for X86 LZCNT instruction selection. llvm-svn: 141652
2011-10-11 14:47:01 +08:00
}
define i16 @t2(i16 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t2:
; X86: # %bb.0:
; X86-NEXT: lzcntw {{[0-9]+}}(%esp), %ax
; X86-NEXT: retl
;
; X32-LABEL: t2:
; X32: # %bb.0:
; X32-NEXT: lzcntw %di, %ax
; X32-NEXT: retq
;
; X64-LABEL: t2:
; X64: # %bb.0:
; X64-NEXT: lzcntw %di, %ax
; X64-NEXT: retq
Manually upgrade the test suite to specify the flag to cttz and ctlz. I followed three heuristics for deciding whether to set 'true' or 'false': - Everything target independent got 'true' as that is the expected common output of the GCC builtins. - If the target arch only has one way of implementing this operation, set the flag in the way that exercises the most of codegen. For most architectures this is also the likely path from a GCC builtin, with 'true' being set. It will (eventually) require lowering away that difference, and then lowering to the architecture's operation. - Otherwise, set the flag differently dependending on which target operation should be tested. Let me know if anyone has any issue with this pattern or would like specific tests of another form. This should allow the x86 codegen to just iteratively improve as I teach the backend how to differentiate between the two forms, and everything else should remain exactly the same. llvm-svn: 146370
2011-12-12 19:59:10 +08:00
%tmp = tail call i16 @llvm.ctlz.i16( i16 %x, i1 false )
Test case for X86 LZCNT instruction selection. llvm-svn: 141652
2011-10-11 14:47:01 +08:00
ret i16 %tmp
}
Cleanup this test a bit, sorting things and grouping them more clearly. llvm-svn: 147243
2011-12-24 18:55:42 +08:00
define i32 @t3(i32 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t3:
; X86: # %bb.0:
; X86-NEXT: lzcntl {{[0-9]+}}(%esp), %eax
; X86-NEXT: retl
;
; X32-LABEL: t3:
; X32: # %bb.0:
; X32-NEXT: lzcntl %edi, %eax
; X32-NEXT: retq
;
; X64-LABEL: t3:
; X64: # %bb.0:
; X64-NEXT: lzcntl %edi, %eax
; X64-NEXT: retq
Cleanup this test a bit, sorting things and grouping them more clearly. llvm-svn: 147243
2011-12-24 18:55:42 +08:00
%tmp = tail call i32 @llvm.ctlz.i32( i32 %x, i1 false )
ret i32 %tmp
Test case for X86 LZCNT instruction selection. llvm-svn: 141652
2011-10-11 14:47:01 +08:00
}
Cleanup this test a bit, sorting things and grouping them more clearly. llvm-svn: 147243
2011-12-24 18:55:42 +08:00
define i64 @t4(i64 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t4:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: testl %eax, %eax
; X86-NEXT: jne .LBB3_1
; X86-NEXT: # %bb.2:
; X86-NEXT: lzcntl {{[0-9]+}}(%esp), %eax
; X86-NEXT: addl $32, %eax
; X86-NEXT: xorl %edx, %edx
; X86-NEXT: retl
; X86-NEXT: .LBB3_1:
; X86-NEXT: lzcntl %eax, %eax
; X86-NEXT: xorl %edx, %edx
; X86-NEXT: retl
;
; X32-LABEL: t4:
; X32: # %bb.0:
; X32-NEXT: lzcntq %rdi, %rax
; X32-NEXT: retq
;
; X64-LABEL: t4:
; X64: # %bb.0:
; X64-NEXT: lzcntq %rdi, %rax
; X64-NEXT: retq
Cleanup this test a bit, sorting things and grouping them more clearly. llvm-svn: 147243
2011-12-24 18:55:42 +08:00
%tmp = tail call i64 @llvm.ctlz.i64( i64 %x, i1 false )
ret i64 %tmp
Test case for X86 LZCNT instruction selection. llvm-svn: 141652
2011-10-11 14:47:01 +08:00
}
Switch the lowering of CTLZ_ZERO_UNDEF from a .td pattern back to the X86ISelLowering C++ code. Because this is lowered via an xor wrapped around a bsr, we want the dagcombine which runs after isel lowering to have a chance to clean things up. In particular, it is very common to see code which looks like: (sizeof(x)*8 - 1) ^ __builtin_clz(x) Which is trying to compute the most significant bit of 'x'. That's actually the value computed directly by the 'bsr' instruction, but if we match it too late, we'll get completely redundant xor instructions. The more naive code for the above (subtracting rather than using an xor) still isn't handled correctly due to the dagcombine getting confused. Also, while here fix an issue spotted by inspection: we should have been expanding the zero-undef variants to the normal variants when there is an 'lzcnt' instruction. Do so, and test for this. We don't want to generate unnecessary 'bsr' instructions. These two changes fix some regressions in encoding and decoding benchmarks. However, there is still a *lot* to be improve on in this type of code. llvm-svn: 147244
2011-12-24 18:55:54 +08:00
define i8 @t5(i8 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t5:
; X86: # %bb.0:
; X86-NEXT: movzbl {{[0-9]+}}(%esp), %eax
; X86-NEXT: lzcntl %eax, %eax
; X86-NEXT: addl $-24, %eax
; X86-NEXT: # kill: def $al killed $al killed $eax
; X86-NEXT: retl
;
; X32-LABEL: t5:
; X32: # %bb.0:
; X32-NEXT: movzbl %dil, %eax
; X32-NEXT: lzcntl %eax, %eax
; X32-NEXT: addl $-24, %eax
; X32-NEXT: # kill: def $al killed $al killed $eax
; X32-NEXT: retq
;
; X64-LABEL: t5:
; X64: # %bb.0:
; X64-NEXT: movzbl %dil, %eax
; X64-NEXT: lzcntl %eax, %eax
; X64-NEXT: addl $-24, %eax
; X64-NEXT: # kill: def $al killed $al killed $eax
; X64-NEXT: retq
Switch the lowering of CTLZ_ZERO_UNDEF from a .td pattern back to the X86ISelLowering C++ code. Because this is lowered via an xor wrapped around a bsr, we want the dagcombine which runs after isel lowering to have a chance to clean things up. In particular, it is very common to see code which looks like: (sizeof(x)*8 - 1) ^ __builtin_clz(x) Which is trying to compute the most significant bit of 'x'. That's actually the value computed directly by the 'bsr' instruction, but if we match it too late, we'll get completely redundant xor instructions. The more naive code for the above (subtracting rather than using an xor) still isn't handled correctly due to the dagcombine getting confused. Also, while here fix an issue spotted by inspection: we should have been expanding the zero-undef variants to the normal variants when there is an 'lzcnt' instruction. Do so, and test for this. We don't want to generate unnecessary 'bsr' instructions. These two changes fix some regressions in encoding and decoding benchmarks. However, there is still a *lot* to be improve on in this type of code. llvm-svn: 147244
2011-12-24 18:55:54 +08:00
%tmp = tail call i8 @llvm.ctlz.i8( i8 %x, i1 true )
ret i8 %tmp
}
define i16 @t6(i16 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t6:
; X86: # %bb.0:
; X86-NEXT: lzcntw {{[0-9]+}}(%esp), %ax
; X86-NEXT: retl
;
; X32-LABEL: t6:
; X32: # %bb.0:
; X32-NEXT: lzcntw %di, %ax
; X32-NEXT: retq
;
; X64-LABEL: t6:
; X64: # %bb.0:
; X64-NEXT: lzcntw %di, %ax
; X64-NEXT: retq
Switch the lowering of CTLZ_ZERO_UNDEF from a .td pattern back to the X86ISelLowering C++ code. Because this is lowered via an xor wrapped around a bsr, we want the dagcombine which runs after isel lowering to have a chance to clean things up. In particular, it is very common to see code which looks like: (sizeof(x)*8 - 1) ^ __builtin_clz(x) Which is trying to compute the most significant bit of 'x'. That's actually the value computed directly by the 'bsr' instruction, but if we match it too late, we'll get completely redundant xor instructions. The more naive code for the above (subtracting rather than using an xor) still isn't handled correctly due to the dagcombine getting confused. Also, while here fix an issue spotted by inspection: we should have been expanding the zero-undef variants to the normal variants when there is an 'lzcnt' instruction. Do so, and test for this. We don't want to generate unnecessary 'bsr' instructions. These two changes fix some regressions in encoding and decoding benchmarks. However, there is still a *lot* to be improve on in this type of code. llvm-svn: 147244
2011-12-24 18:55:54 +08:00
%tmp = tail call i16 @llvm.ctlz.i16( i16 %x, i1 true )
ret i16 %tmp
}
define i32 @t7(i32 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t7:
; X86: # %bb.0:
; X86-NEXT: lzcntl {{[0-9]+}}(%esp), %eax
; X86-NEXT: retl
;
; X32-LABEL: t7:
; X32: # %bb.0:
; X32-NEXT: lzcntl %edi, %eax
; X32-NEXT: retq
;
; X64-LABEL: t7:
; X64: # %bb.0:
; X64-NEXT: lzcntl %edi, %eax
; X64-NEXT: retq
Switch the lowering of CTLZ_ZERO_UNDEF from a .td pattern back to the X86ISelLowering C++ code. Because this is lowered via an xor wrapped around a bsr, we want the dagcombine which runs after isel lowering to have a chance to clean things up. In particular, it is very common to see code which looks like: (sizeof(x)*8 - 1) ^ __builtin_clz(x) Which is trying to compute the most significant bit of 'x'. That's actually the value computed directly by the 'bsr' instruction, but if we match it too late, we'll get completely redundant xor instructions. The more naive code for the above (subtracting rather than using an xor) still isn't handled correctly due to the dagcombine getting confused. Also, while here fix an issue spotted by inspection: we should have been expanding the zero-undef variants to the normal variants when there is an 'lzcnt' instruction. Do so, and test for this. We don't want to generate unnecessary 'bsr' instructions. These two changes fix some regressions in encoding and decoding benchmarks. However, there is still a *lot* to be improve on in this type of code. llvm-svn: 147244
2011-12-24 18:55:54 +08:00
%tmp = tail call i32 @llvm.ctlz.i32( i32 %x, i1 true )
ret i32 %tmp
}
define i64 @t8(i64 %x) nounwind {
[X86] Regenerate LZCNT tests on x86/x32/x64 targets llvm-svn: 361495
2019-05-23 21:30:10 +08:00
; X86-LABEL: t8:
; X86: # %bb.0:
; X86-NEXT: movl {{[0-9]+}}(%esp), %eax
; X86-NEXT: testl %eax, %eax
; X86-NEXT: jne .LBB7_1
; X86-NEXT: # %bb.2:
; X86-NEXT: lzcntl {{[0-9]+}}(%esp), %eax
; X86-NEXT: addl $32, %eax
; X86-NEXT: xorl %edx, %edx
; X86-NEXT: retl
; X86-NEXT: .LBB7_1:
; X86-NEXT: lzcntl %eax, %eax
; X86-NEXT: xorl %edx, %edx
; X86-NEXT: retl
;
; X32-LABEL: t8:
; X32: # %bb.0:
; X32-NEXT: lzcntq %rdi, %rax
; X32-NEXT: retq
;
; X64-LABEL: t8:
; X64: # %bb.0:
; X64-NEXT: lzcntq %rdi, %rax
; X64-NEXT: retq
Switch the lowering of CTLZ_ZERO_UNDEF from a .td pattern back to the X86ISelLowering C++ code. Because this is lowered via an xor wrapped around a bsr, we want the dagcombine which runs after isel lowering to have a chance to clean things up. In particular, it is very common to see code which looks like: (sizeof(x)*8 - 1) ^ __builtin_clz(x) Which is trying to compute the most significant bit of 'x'. That's actually the value computed directly by the 'bsr' instruction, but if we match it too late, we'll get completely redundant xor instructions. The more naive code for the above (subtracting rather than using an xor) still isn't handled correctly due to the dagcombine getting confused. Also, while here fix an issue spotted by inspection: we should have been expanding the zero-undef variants to the normal variants when there is an 'lzcnt' instruction. Do so, and test for this. We don't want to generate unnecessary 'bsr' instructions. These two changes fix some regressions in encoding and decoding benchmarks. However, there is still a *lot* to be improve on in this type of code. llvm-svn: 147244
2011-12-24 18:55:54 +08:00
%tmp = tail call i64 @llvm.ctlz.i64( i64 %x, i1 true )
ret i64 %tmp
}