RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-30 23:42:52 +01:00
Code Issues Projects Releases Wiki Activity
b51d0cd53b
llvm-mirror/test/CodeGen/Generic/2008-02-04-Ctlz.ll

22 lines
922 B
LLVM
Raw Normal View History

Eliminate more uses of llvm-as and llvm-dis. llvm-svn: 81293
2009-09-09 02:09:15 +02:00
; RUN: llc < %s
Crashes LegalizeTypes with "Do not know how to expand the result of this operator!" (node: ctlz). llvm-svn: 46713
2008-02-04 19:07:02 +01:00
Teach LegalizeTypes how to expand and promote CTLZ, CTTZ and CTPOP. The expansion code differs from that in LegalizeDAG in that it chooses to take the CTLZ/CTTZ count from the Hi/Lo part depending on whether the Hi/Lo value is zero, not on whether CTLZ/CTTZ of Hi/Lo returned 32 (or whatever the width of the type is) for it. I made this change because the optimizers may well know that Hi/Lo is zero and exploit it. The promotion code for CTTZ also differs from that in LegalizeDAG: it uses an "or" to get the right result when the original value is zero, rather than using a compare and select. This also means the value doesn't need to be zero extended. llvm-svn: 47075
2008-02-13 19:01:53 +01:00
@.str = internal constant [14 x i8] c"%lld %d %d %d\00"
Crashes LegalizeTypes with "Do not know how to expand the result of this operator!" (node: ctlz). llvm-svn: 46713
2008-02-04 19:07:02 +01:00
Teach LegalizeTypes how to expand and promote CTLZ, CTTZ and CTPOP. The expansion code differs from that in LegalizeDAG in that it chooses to take the CTLZ/CTTZ count from the Hi/Lo part depending on whether the Hi/Lo value is zero, not on whether CTLZ/CTTZ of Hi/Lo returned 32 (or whatever the width of the type is) for it. I made this change because the optimizers may well know that Hi/Lo is zero and exploit it. The promotion code for CTTZ also differs from that in LegalizeDAG: it uses an "or" to get the right result when the original value is zero, rather than using a compare and select. This also means the value doesn't need to be zero extended. llvm-svn: 47075
2008-02-13 19:01:53 +01:00
define i32 @main(i64 %arg) nounwind {
Crashes LegalizeTypes with "Do not know how to expand the result of this operator!" (node: ctlz). llvm-svn: 46713
2008-02-04 19:07:02 +01:00
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 12:59:10 +01:00
%tmp37 = tail call i64 @llvm.ctlz.i64( i64 %arg, i1 true ) ; <i64> [#uses=1]
%tmp47 = tail call i64 @llvm.cttz.i64( i64 %arg, i1 true ) ; <i64> [#uses=1]
Teach LegalizeTypes how to expand and promote CTLZ, CTTZ and CTPOP. The expansion code differs from that in LegalizeDAG in that it chooses to take the CTLZ/CTTZ count from the Hi/Lo part depending on whether the Hi/Lo value is zero, not on whether CTLZ/CTTZ of Hi/Lo returned 32 (or whatever the width of the type is) for it. I made this change because the optimizers may well know that Hi/Lo is zero and exploit it. The promotion code for CTTZ also differs from that in LegalizeDAG: it uses an "or" to get the right result when the original value is zero, rather than using a compare and select. This also means the value doesn't need to be zero extended. llvm-svn: 47075
2008-02-13 19:01:53 +01:00
%tmp57 = tail call i64 @llvm.ctpop.i64( i64 %arg ) ; <i64> [#uses=1]
%tmp38 = trunc i64 %tmp37 to i32 ; <i32>:0 [#uses=1]
%tmp48 = trunc i64 %tmp47 to i32 ; <i32>:0 [#uses=1]
%tmp58 = trunc i64 %tmp57 to i32 ; <i32>:0 [#uses=1]
%tmp40 = tail call i32 (i8*, ...)* @printf( i8* noalias getelementptr ([14 x i8]* @.str, i32 0, i32 0), i64 %arg, i32 %tmp38, i32 %tmp48, i32 %tmp58 ) nounwind ; <i32> [#uses=0]
Crashes LegalizeTypes with "Do not know how to expand the result of this operator!" (node: ctlz). llvm-svn: 46713
2008-02-04 19:07:02 +01:00
ret i32 0
}
declare i32 @printf(i8* noalias , ...) nounwind
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) nounwind readnone
declare i64 @llvm.cttz.i64(i64, i1) nounwind readnone
Teach LegalizeTypes how to expand and promote CTLZ, CTTZ and CTPOP. The expansion code differs from that in LegalizeDAG in that it chooses to take the CTLZ/CTTZ count from the Hi/Lo part depending on whether the Hi/Lo value is zero, not on whether CTLZ/CTTZ of Hi/Lo returned 32 (or whatever the width of the type is) for it. I made this change because the optimizers may well know that Hi/Lo is zero and exploit it. The promotion code for CTTZ also differs from that in LegalizeDAG: it uses an "or" to get the right result when the original value is zero, rather than using a compare and select. This also means the value doesn't need to be zero extended. llvm-svn: 47075
2008-02-13 19:01:53 +01:00
declare i64 @llvm.ctpop.i64(i64) nounwind readnone
Reference in New Issue Copy Permalink