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

74 lines
2.4 KiB
LLVM
Raw Normal View History

Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
; RUN: llvm-as < %s | llvm-dis > %t1.ll
Added RUN lines and dejagnu support for Feature dir. llvm-svn: 17568
2004-11-07 14:08:43 +08:00
; RUN: llvm-as %t1.ll -o - | llvm-dis > %t2.ll
; RUN: diff %t1.ll %t2.ll
rdar://11542750 - llvm.trap should be marked no return. llvm-svn: 157551
2012-05-28 07:20:41 +08:00
; RUN: FileCheck %s < %t1.ll
Added RUN lines and dejagnu support for Feature dir. llvm-svn: 17568
2004-11-07 14:08:43 +08:00
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
declare i1 @llvm.isunordered.f32(float, float)
I misled Alkis: LLVM should have isnan, not isunordered. isunordered(X, Y) === isnan(X) | isnan(Y) Remove isunordered, add isnan. Modernize testcase llvm-svn: 14133
2004-06-11 10:29:57 +08:00
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
declare i1 @llvm.isunordered.f64(double, double)
Add the isunordered intrinsic. llvm-svn: 14159
2004-06-13 03:19:14 +08:00
Add a test for llvm.prefetch. llvm-svn: 20379
2005-03-01 03:31:42 +08:00
Upgrade these tests for the current intrinsic prototypes. llvm-svn: 49669
2008-04-15 02:19:18 +08:00
declare i8 @llvm.ctpop.i8(i8)
Expand test to cover the non-overloaded variants of the arithmetic and floating point intrinsics. llvm-svn: 25431
2006-01-19 09:17:06 +08:00
Upgrade these tests for the current intrinsic prototypes. llvm-svn: 49669
2008-04-15 02:19:18 +08:00
declare i16 @llvm.ctpop.i16(i16)
Expand test to cover the non-overloaded variants of the arithmetic and floating point intrinsics. llvm-svn: 25431
2006-01-19 09:17:06 +08:00
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
declare i32 @llvm.ctpop.i32(i32)
Expand test to cover the non-overloaded variants of the arithmetic and floating point intrinsics. llvm-svn: 25431
2006-01-19 09:17:06 +08:00
Upgrade these tests for the current intrinsic prototypes. llvm-svn: 49669
2008-04-15 02:19:18 +08:00
declare i64 @llvm.ctpop.i64(i64)
pre add count tests llvm-svn: 21671
2005-05-04 00:49:48 +08: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 19:59:10 +08:00
declare i8 @llvm.cttz.i8(i8, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08: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 19:59:10 +08:00
declare i16 @llvm.cttz.i16(i16, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08: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 19:59:10 +08:00
declare i32 @llvm.cttz.i32(i32, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08: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 19:59:10 +08:00
declare i64 @llvm.cttz.i64(i64, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08: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 19:59:10 +08:00
declare i8 @llvm.ctlz.i8(i8, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08: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 19:59:10 +08:00
declare i16 @llvm.ctlz.i16(i16, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08: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 19:59:10 +08:00
declare i32 @llvm.ctlz.i32(i32, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08: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 19:59:10 +08:00
declare i64 @llvm.ctlz.i64(i64, i1)
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
declare float @llvm.sqrt.f32(float)
declare double @llvm.sqrt.f64(double)
Add feature test for llvm intrinsics. It currently contains only the "isunordered" intrinsic llvm-svn: 14126
2004-06-11 09:06:40 +08:00
; Test llvm intrinsics
;
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
define void @libm() {
fcmp uno float 1.000000e+00, 2.000000e+00 ; <i1>:1 [#uses=0]
fcmp uno double 3.000000e+00, 4.000000e+00 ; <i1>:2 [#uses=0]
call float @llvm.sqrt.f32( float 5.000000e+00 ) ; <float>:3 [#uses=0]
call double @llvm.sqrt.f64( double 6.000000e+00 ) ; <double>:4 [#uses=0]
Upgrade these tests for the current intrinsic prototypes. llvm-svn: 49669
2008-04-15 02:19:18 +08:00
call i8 @llvm.ctpop.i8( i8 10 ) ; <i32>:5 [#uses=0]
call i16 @llvm.ctpop.i16( i16 11 ) ; <i32>:6 [#uses=0]
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
call i32 @llvm.ctpop.i32( i32 12 ) ; <i32>:7 [#uses=0]
Upgrade these tests for the current intrinsic prototypes. llvm-svn: 49669
2008-04-15 02:19:18 +08:00
call i64 @llvm.ctpop.i64( i64 13 ) ; <i32>:8 [#uses=0]
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
call i8 @llvm.ctlz.i8( i8 14, i1 true ) ; <i32>:9 [#uses=0]
call i16 @llvm.ctlz.i16( i16 15, i1 true ) ; <i32>:10 [#uses=0]
call i32 @llvm.ctlz.i32( i32 16, i1 true ) ; <i32>:11 [#uses=0]
call i64 @llvm.ctlz.i64( i64 17, i1 true ) ; <i32>:12 [#uses=0]
call i8 @llvm.cttz.i8( i8 18, i1 true ) ; <i32>:13 [#uses=0]
call i16 @llvm.cttz.i16( i16 19, i1 true ) ; <i32>:14 [#uses=0]
call i32 @llvm.cttz.i32( i32 20, i1 true ) ; <i32>:15 [#uses=0]
call i64 @llvm.cttz.i64( i64 21, i1 true ) ; <i32>:16 [#uses=0]
Remove llvm-upgrade and update tests. llvm-svn: 47784
2008-03-01 15:38:40 +08:00
ret void
I misled Alkis: LLVM should have isnan, not isunordered. isunordered(X, Y) === isnan(X) | isnan(Y) Remove isunordered, add isnan. Modernize testcase llvm-svn: 14133
2004-06-11 10:29:57 +08:00
}
Add note to self to complete the testing of all intrinsic functions as specified in the LangRef document. llvm-svn: 21807
2005-05-09 12:47:32 +08:00
; FIXME: test ALL the intrinsics in this file.
rdar://11542750 - llvm.trap should be marked no return. llvm-svn: 157551
2012-05-28 07:20:41 +08:00
; rdar://11542750
Change math intrinsic attributes from readonly to readnone. These are operations that do not access memory but may be sensitive to floating-point environment changes. LLVM does not attempt to model FP environment changes, so this was unnecessarily conservative and was getting on the way of some optimizations, in particular SLP vectorization. llvm-svn: 203037
2014-03-06 08:18:15 +08:00
; CHECK: declare void @llvm.trap() #1
rdar://11542750 - llvm.trap should be marked no return. llvm-svn: 157551
2012-05-28 07:20:41 +08:00
declare void @llvm.trap()
define void @trap() {
call void @llvm.trap()
ret void
}
Modify the LLVM assembly output so that it uses references to represent function attributes. This makes the LLVM assembly look better. E.g.: define void @foo() #0 { ret void } attributes #0 = { nounwind noinline ssp } llvm-svn: 175605
2013-02-20 15:21:42 +08:00
Replace hardcoded intrinsic list with speculatable attribute. No change in which intrinsics should be speculated. llvm-svn: 301995
2017-05-03 10:26:10 +08:00
; CHECK: attributes #0 = { nounwind readnone speculatable }
Mark @llvm.trap cold A call to @llvm.trap can be expected to be cold (i.e. unlikely to be reached in a normal program execution). Outlining paths which unconditionally trap is an important memory saving. As the hot/cold splitting pass (imho) should not treat all noreturn calls as cold, explicitly mark @llvm.trap cold so that it can be outlined. Split out of https://reviews.llvm.org/D54244. Differential Revision: https://reviews.llvm.org/D54329 llvm-svn: 346885
2018-11-15 03:53:41 +08:00
; CHECK: attributes #1 = { cold noreturn nounwind }