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/Mips/2010-11-09-CountLeading.ll

34 lines
730 B
LLVM
Raw Normal View History

Fix test cases. Generate code for Mips32r1 unless a Mips32r2 feature is tested. llvm-svn: 139433
2011-09-10 07:14:58 +08:00
; RUN: llc -march=mips < %s | FileCheck %s
Add a test to the previous added clo instruction. Patch by Akira again llvm-svn: 118668
2010-11-10 10:22:44 +08:00
; CHECK: clz $2, $4
define i32 @t1(i32 %X) nounwind readnone {
entry:
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
%tmp1 = tail call i32 @llvm.ctlz.i32(i32 %X, i1 true)
Add a test to the previous added clo instruction. Patch by Akira again llvm-svn: 118668
2010-11-10 10:22:44 +08:00
ret i32 %tmp1
}
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
declare i32 @llvm.ctlz.i32(i32, i1) nounwind readnone
Add a test to the previous added clo instruction. Patch by Akira again llvm-svn: 118668
2010-11-10 10:22:44 +08:00
; CHECK: clz $2, $4
define i32 @t2(i32 %X) nounwind readnone {
entry:
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
%tmp1 = tail call i32 @llvm.ctlz.i32(i32 %X, i1 true)
Add a test to the previous added clo instruction. Patch by Akira again llvm-svn: 118668
2010-11-10 10:22:44 +08:00
ret i32 %tmp1
}
; CHECK: clo $2, $4
define i32 @t3(i32 %X) nounwind readnone {
entry:
%neg = xor i32 %X, -1
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
%tmp1 = tail call i32 @llvm.ctlz.i32(i32 %neg, i1 true)
Add a test to the previous added clo instruction. Patch by Akira again llvm-svn: 118668
2010-11-10 10:22:44 +08:00
ret i32 %tmp1
}
; CHECK: clo $2, $4
define i32 @t4(i32 %X) nounwind readnone {
entry:
%neg = xor i32 %X, -1
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
%tmp1 = tail call i32 @llvm.ctlz.i32(i32 %neg, i1 true)
Add a test to the previous added clo instruction. Patch by Akira again llvm-svn: 118668
2010-11-10 10:22:44 +08:00
ret i32 %tmp1
}