6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-01-01 00:33:09 +00:00
Code Issues Projects Releases Wiki Activity
38c35f3e2c
llvm-6502/test/CodeGen/PowerPC/2007-03-24-cntlzd.ll

21 lines
747 B
LLVM
Raw Normal View History

[PowerPC] Fix test to pass on Darwin hosts git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225220 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 23:17:43 +00:00
; RUN: llc -mcpu=g5 < %s | FileCheck %s
target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
test that the ppc backend can do 64-bit cntlz git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35328 91177308-0d34-0410-b5e6-96231b3b80d8
2007-03-25 04:43:51 +00:00
add some nounwind's. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119086 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-14 22:22:14 +00:00
define i32 @_ZNK4llvm5APInt17countLeadingZerosEv(i64 *%t) nounwind {
test that the ppc backend can do 64-bit cntlz git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35328 91177308-0d34-0410-b5e6-96231b3b80d8
2007-03-25 04:43:51 +00:00
%tmp19 = load i64* %t
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146370 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-12 11:59:10 +00:00
%tmp22 = tail call i64 @llvm.ctlz.i64( i64 %tmp19, i1 true ) ; <i64> [#uses=1]
This is the patch to provide clean intrinsic function overloading support in LLVM. It cleans up the intrinsic definitions and generally smooths the process for more complicated intrinsic writing. It will be used by the upcoming atomic intrinsics as well as vector and float intrinsics in the future. This also changes the syntax for llvm.bswap, llvm.part.set, llvm.part.select, and llvm.ct* intrinsics. They are automatically upgraded by both the LLVM ASM reader and the bitcode reader. The test cases have been updated, with special tests added to ensure the automatic upgrading is supported. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40807 91177308-0d34-0410-b5e6-96231b3b80d8
2007-08-04 01:51:18 +00:00
%tmp23 = trunc i64 %tmp22 to i32
For PR1297: Update these test cases to use proper signatures for bswap which is now and overloaded intrinsic. Its name must be of the form llvm.bswap.i32.i32 since both the parameter and the result or of type "iAny". Also, the bit counting intrinsics changed to always return i32. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35548 91177308-0d34-0410-b5e6-96231b3b80d8
2007-04-01 07:36:28 +00:00
%tmp89 = add i32 %tmp23, -64 ; <i32> [#uses=1]
%tmp90 = add i32 %tmp89, 0 ; <i32> [#uses=1]
test that the ppc backend can do 64-bit cntlz git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35328 91177308-0d34-0410-b5e6-96231b3b80d8
2007-03-25 04:43:51 +00:00
ret i32 %tmp90
[PowerPC] Convert a README.txt entry into a better test We now produce the desired code as noted in the README.txt file (no spurious or). Remove the README entry and improve the regression test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225214 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 21:53:52 +00:00
; CHECK-LABEL: @_ZNK4llvm5APInt17countLeadingZerosEv
; CHECK: ld [[REG1:[0-9]+]], 0(3)
; CHECK-NEXT: cntlzd [[REG2:[0-9]+]], [[REG1]]
; CHECK-NEXT: addi 3, [[REG2]], -64
; CHECK-NEXT: blr
test that the ppc backend can do 64-bit cntlz git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35328 91177308-0d34-0410-b5e6-96231b3b80d8
2007-03-25 04:43:51 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146370 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-12 11:59:10 +00:00
declare i64 @llvm.ctlz.i64(i64, i1)
Reference in New Issue Copy Permalink