RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 08:23:21 +01:00
Code Issues Projects Releases Wiki Activity
b71a2e2f2e
llvm-mirror/test/CodeGen/Generic/llvm-ct-intrinsics.ll

63 lines
1.8 KiB
LLVM
Raw Normal View History

new testcase llvm-svn: 21854
2005-05-11 06:22:47 +02:00
; Make sure this testcase is supported by all code generators
Eliminate more uses of llvm-as and llvm-dis. llvm-svn: 81293
2009-09-09 02:09:15 +02:00
; RUN: llc < %s
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
declare i64 @llvm.ctpop.i64(i64)
declare i32 @llvm.ctpop.i32(i32)
declare i16 @llvm.ctpop.i16(i16)
declare i8 @llvm.ctpop.i8(i8)
define void @ctpoptest(i8 %A, i16 %B, i32 %C, i64 %D, i8* %AP, i16* %BP, i32* %CP, i64* %DP) {
%a = call i8 @llvm.ctpop.i8( i8 %A ) ; <i8> [#uses=1]
%b = call i16 @llvm.ctpop.i16( i16 %B ) ; <i16> [#uses=1]
%c = call i32 @llvm.ctpop.i32( i32 %C ) ; <i32> [#uses=1]
%d = call i64 @llvm.ctpop.i64( i64 %D ) ; <i64> [#uses=1]
store i8 %a, i8* %AP
store i16 %b, i16* %BP
store i32 %c, i32* %CP
store i64 %d, i64* %DP
new testcase llvm-svn: 21854
2005-05-11 06:22:47 +02:00
ret void
}
include the other bit count intrinsics llvm-svn: 21863
2005-05-11 07:31:01 +02:00
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 12:59:10 +01:00
declare i64 @llvm.ctlz.i64(i64, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
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 12:59:10 +01:00
declare i32 @llvm.ctlz.i32(i32, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
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 12:59:10 +01:00
declare i16 @llvm.ctlz.i16(i16, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
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 12:59:10 +01:00
declare i8 @llvm.ctlz.i8(i8, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
define void @ctlztest(i8 %A, i16 %B, i32 %C, i64 %D, i8* %AP, i16* %BP, i32* %CP, i64* %DP) {
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 12:59:10 +01:00
%a = call i8 @llvm.ctlz.i8( i8 %A, i1 true ) ; <i8> [#uses=1]
%b = call i16 @llvm.ctlz.i16( i16 %B, i1 true ) ; <i16> [#uses=1]
%c = call i32 @llvm.ctlz.i32( i32 %C, i1 true ) ; <i32> [#uses=1]
%d = call i64 @llvm.ctlz.i64( i64 %D, i1 true ) ; <i64> [#uses=1]
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
store i8 %a, i8* %AP
store i16 %b, i16* %BP
store i32 %c, i32* %CP
store i64 %d, i64* %DP
include the other bit count intrinsics llvm-svn: 21863
2005-05-11 07:31:01 +02:00
ret void
}
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 12:59:10 +01:00
declare i64 @llvm.cttz.i64(i64, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
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 12:59:10 +01:00
declare i32 @llvm.cttz.i32(i32, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
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 12:59:10 +01:00
declare i16 @llvm.cttz.i16(i16, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
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 12:59:10 +01:00
declare i8 @llvm.cttz.i8(i8, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
define void @cttztest(i8 %A, i16 %B, i32 %C, i64 %D, i8* %AP, i16* %BP, i32* %CP, i64* %DP) {
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 12:59:10 +01:00
%a = call i8 @llvm.cttz.i8( i8 %A, i1 true ) ; <i8> [#uses=1]
%b = call i16 @llvm.cttz.i16( i16 %B, i1 true ) ; <i16> [#uses=1]
%c = call i32 @llvm.cttz.i32( i32 %C, i1 true ) ; <i32> [#uses=1]
%d = call i64 @llvm.cttz.i64( i64 %D, i1 true ) ; <i64> [#uses=1]
Remove llvm-upgrade and update tests. llvm-svn: 47296
2008-02-19 02:41:04 +01:00
store i8 %a, i8* %AP
store i16 %b, i16* %BP
store i32 %c, i32* %CP
store i64 %d, i64* %DP
include the other bit count intrinsics llvm-svn: 21863
2005-05-11 07:31:01 +02:00
ret void
}
Reference in New Issue Copy Permalink