| /external/clang/test/CodeGen/ |
| fp16-ops.c | 14 // CHECK: call float @llvm.convert.from.fp16
17 // CHECK: call float @llvm.convert.from.fp16
20 // CHECK: call float @llvm.convert.from.fp16
22 // CHECK: call i16 @llvm.convert.to.fp16
24 // CHECK: call float @llvm.convert.from.fp16
25 // CHECK: call i16 @llvm.convert.to.fp16
27 // CHECK: call float @llvm.convert.from.fp16
29 // CHECK: call i16 @llvm.convert.to.fp16
31 // CHECK: call float @llvm.convert.from.fp16
33 // CHECK: call i16 @llvm.convert.to.fp16
[all...] |
| /external/llvm/test/CodeGen/ARM/ |
| fp16.ll | 2 ; RUN: llc -mattr=+vfp3,+fp16 < %s | FileCheck --check-prefix=CHECK-FP16 %s
16 %2 = tail call float @llvm.convert.from.fp16(i16 %0)
18 ; CHECK-FP16: vcvtb.f32.f16
19 %3 = tail call float @llvm.convert.from.fp16(i16 %1)
21 ; CHECK-FP16: vcvtb.f32.f16
23 %5 = tail call i16 @llvm.convert.to.fp16(float %4)
25 ; CHECK-FP16: vcvtb.f16.f32
30 declare float @llvm.convert.from.fp16(i16) nounwind readnone
32 declare i16 @llvm.convert.to.fp16(float) nounwind readnon
[all...] |
| vcvt.ll | 1 ; RUN: llc < %s -march=arm -mattr=+neon,+fp16 | FileCheck %s
|
| /dalvik/vm/compiler/codegen/arm/ |
| ArmRallocUtil.cpp | 47 * fp16-fp31: Promotion pool
|
| /external/chromium_org/third_party/mesa/src/src/gallium/drivers/nv30/ |
| nvfx_shader.h | 83 * 7: destination register is fp16?? (use for outputs)
92 * 22-23: precision 0 = fp32, 1 = fp16, 2 = s1.10 fixed, 3 = s0.8 fixed (nv40-only))
111 * 19-20: input precision 0 = fp32, 1 = fp16, 2 = s1.10 fixed, 3 = ???
125 * 8: source register is fp16??
|
| nvfx_fragprog.c | 249 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
273 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
292 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
309 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
336 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
360 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
630 * NOTE: if we start using half precision, we might need an fp16 FLT_MIN here instead
[all...] |
| /external/chromium_org/third_party/mesa/src/src/gallium/drivers/r300/ |
| r300_chipset.h | 77 * - FP16 blending and multisampling
|
| r300_context.h | 108 /* The same, but for FP16 alpha test. */
|
| r300_texture_desc.c | 72 /* XXX FP16 AA. */
|
| r300_state.c | 318 * Discarding pixels must be disabled when FP16 AA is enabled.
[all...] |
| /external/mesa3d/src/gallium/drivers/nv30/ |
| nvfx_shader.h | 83 * 7: destination register is fp16?? (use for outputs)
92 * 22-23: precision 0 = fp32, 1 = fp16, 2 = s1.10 fixed, 3 = s0.8 fixed (nv40-only))
111 * 19-20: input precision 0 = fp32, 1 = fp16, 2 = s1.10 fixed, 3 = ???
125 * 8: source register is fp16??
|
| nvfx_fragprog.c | 249 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
273 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
292 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
309 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
336 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
360 /* I really wonder why fp16 precision is used. Presumably the hardware ignores it? */
630 * NOTE: if we start using half precision, we might need an fp16 FLT_MIN here instead
[all...] |
| /external/mesa3d/src/gallium/drivers/r300/ |
| r300_chipset.h | 77 * - FP16 blending and multisampling
|
| r300_context.h | 108 /* The same, but for FP16 alpha test. */
|
| r300_texture_desc.c | 72 /* XXX FP16 AA. */
|
| /ndk/sources/android/cpufeatures/ |
| cpu-features.c | 682 // 'vfpv4' implies VFPv3|VFP_FMA|FP16
1032 * {"vfpv3-fp16", FPU_ARCH_VFP_V3_FP16},
1034 * {"vfpv3-d16-fp16", FPU_ARCH_VFP_V3D16_FP16},
1036 * {"vfpv3xd-fp16", FPU_ARCH_VFP_V3xD_FP16},
1038 * {"neon-fp16", FPU_ARCH_NEON_FP16},
[all...] |
| /external/llvm/lib/Target/ARM/ |
| ARM.td | 43 def FeatureFP16 : SubtargetFeature<"fp16", "HasFP16", "true",
|
| /external/llvm/lib/Support/ |
| Host.cpp | 586 .Case("half", "fp16")
|
| /external/llvm/docs/ |
| LangRef.rst | [all...] |
| /prebuilts/gcc/darwin-x86/arm/arm-eabi-4.6/lib/gcc/arm-eabi/4.6.x-google/plugin/include/config/arm/ |
| arm.h | 269 (TARGET_VFP && arm_fpu_desc->neon && arm_fpu_desc->fp16)
272 #define TARGET_FP16 (TARGET_VFP && arm_fpu_desc->fp16)
365 int fp16;
363 int fp16; member in struct:arm_fpu_desc
[all...] |
| /prebuilts/gcc/darwin-x86/arm/arm-linux-androideabi-4.6/lib/gcc/arm-linux-androideabi/4.6.x-google/plugin/include/config/arm/ |
| arm.h | 269 (TARGET_VFP && arm_fpu_desc->neon && arm_fpu_desc->fp16)
272 #define TARGET_FP16 (TARGET_VFP && arm_fpu_desc->fp16)
365 int fp16;
363 int fp16; member in struct:arm_fpu_desc
[all...] |
| /prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/lib/gcc/arm-eabi/4.6.x-google/plugin/include/config/arm/ |
| arm.h | 269 (TARGET_VFP && arm_fpu_desc->neon && arm_fpu_desc->fp16)
272 #define TARGET_FP16 (TARGET_VFP && arm_fpu_desc->fp16)
365 int fp16;
363 int fp16; member in struct:arm_fpu_desc
[all...] |
| /prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/lib/gcc/arm-linux-androideabi/4.6.x-google/plugin/include/config/arm/ |
| arm.h | 269 (TARGET_VFP && arm_fpu_desc->neon && arm_fpu_desc->fp16)
272 #define TARGET_FP16 (TARGET_VFP && arm_fpu_desc->fp16)
365 int fp16;
363 int fp16; member in struct:arm_fpu_desc
[all...] |
| /external/llvm/include/llvm/CodeGen/ |
| ISDOpcodes.h | 437 /// numbers. We need special nodes since FP16 is a storage-only type with
[all...] |
| /external/llvm/lib/Analysis/ |
| ConstantFolding.cpp | [all...] |
