maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/arm-neon-directed-rounding-...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

66 lines
3.7 KiB
C
Raw Normal View History

[FPEnv][AArch64] Platform-specific builtin constrained FP enablement When constrained floating point is enabled the AArch64-specific builtins don't use constrained intrinsics in some cases. Fix that. Neon is part of this patch, so ARM is affected as well. Differential Revision: https://reviews.llvm.org/D77074
2020-04-11 00:35:42 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57 \
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | FileCheck -check-prefixes=COMMON,COMMONIR,UNCONSTRAINED %s
// RUN: %clang_cc1 -triple arm64-linux-gnueabihf -target-feature +neon \
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | FileCheck -check-prefixes=COMMON,COMMONIR,UNCONSTRAINED %s
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57 \
// RUN: -ffp-exception-behavior=strict \
Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support." We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Use the new -fexperimental-strict-floating-point flag to force allowing strict floating point on hosts that aren't already marked as supporting it (X86 and SystemZ). Differential Revision: https://reviews.llvm.org/D80952
2020-07-10 20:46:09 +08:00
// RUN: -fexperimental-strict-floating-point \
[FPEnv][AArch64] Platform-specific builtin constrained FP enablement When constrained floating point is enabled the AArch64-specific builtins don't use constrained intrinsics in some cases. Fix that. Neon is part of this patch, so ARM is affected as well. Differential Revision: https://reviews.llvm.org/D77074
2020-04-11 00:35:42 +08:00
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | FileCheck -check-prefixes=COMMON,COMMONIR,CONSTRAINED %s
// RUN: %clang_cc1 -triple arm64-linux-gnueabihf -target-feature +neon \
// RUN: -ffp-exception-behavior=strict \
Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support." We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Use the new -fexperimental-strict-floating-point flag to force allowing strict floating point on hosts that aren't already marked as supporting it (X86 and SystemZ). Differential Revision: https://reviews.llvm.org/D80952
2020-07-10 20:46:09 +08:00
// RUN: -fexperimental-strict-floating-point \
[FPEnv][AArch64] Platform-specific builtin constrained FP enablement When constrained floating point is enabled the AArch64-specific builtins don't use constrained intrinsics in some cases. Fix that. Neon is part of this patch, so ARM is affected as well. Differential Revision: https://reviews.llvm.org/D77074
2020-04-11 00:35:42 +08:00
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | FileCheck -check-prefixes=COMMON,COMMONIR,CONSTRAINED %s
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57 \
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | llc -o=- - | FileCheck -check-prefixes=COMMON,CHECK-ASM32 %s
// RUN: %clang_cc1 -triple arm64-linux-gnueabihf -target-feature +neon \
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | llc -o=- - | FileCheck -check-prefixes=COMMON,CHECK-ASM64 %s
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57 \
// RUN: -ffp-exception-behavior=strict \
Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support." We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Use the new -fexperimental-strict-floating-point flag to force allowing strict floating point on hosts that aren't already marked as supporting it (X86 and SystemZ). Differential Revision: https://reviews.llvm.org/D80952
2020-07-10 20:46:09 +08:00
// RUN: -fexperimental-strict-floating-point \
[FPEnv][AArch64] Platform-specific builtin constrained FP enablement When constrained floating point is enabled the AArch64-specific builtins don't use constrained intrinsics in some cases. Fix that. Neon is part of this patch, so ARM is affected as well. Differential Revision: https://reviews.llvm.org/D77074
2020-04-11 00:35:42 +08:00
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | llc -o=- - | FileCheck -check-prefixes=COMMON,CHECK-ASM32 %s
// RUN: %clang_cc1 -triple arm64-linux-gnueabihf -target-feature +neon \
// RUN: -ffp-exception-behavior=strict \
Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support." We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Use the new -fexperimental-strict-floating-point flag to force allowing strict floating point on hosts that aren't already marked as supporting it (X86 and SystemZ). Differential Revision: https://reviews.llvm.org/D80952
2020-07-10 20:46:09 +08:00
// RUN: -fexperimental-strict-floating-point \
[FPEnv][AArch64] Platform-specific builtin constrained FP enablement When constrained floating point is enabled the AArch64-specific builtins don't use constrained intrinsics in some cases. Fix that. Neon is part of this patch, so ARM is affected as well. Differential Revision: https://reviews.llvm.org/D77074
2020-04-11 00:35:42 +08:00
// RUN: -ffreestanding -disable-O0-optnone -emit-llvm %s -o - | \
// RUN: opt -S -mem2reg | llc -o=- - | FileCheck -check-prefixes=COMMON,CHECK-ASM64 %s
// REQUIRES: arm-registered-target,aarch64-registered-target
#include <arm_neon.h>
// COMMON-LABEL: test_vrndi_f32
// COMMONIR: [[TMP0:%.*]] = bitcast <2 x float> %a to <8 x i8>
// UNCONSTRAINED: [[VRNDI1_I:%.*]] = call <2 x float> @llvm.nearbyint.v2f32(<2 x float> %a)
// CONSTRAINED: [[VRNDI1_I:%.*]] = call <2 x float> @llvm.experimental.constrained.nearbyint.v2f32(<2 x float> %a, metadata !"round.tonearest", metadata !"fpexcept.strict")
// CHECK-ASM32: vrintr.f32 s{{[0-9]+}}, s{{[0-9]+}}
// CHECK-ASM32: vrintr.f32 s{{[0-9]+}}, s{{[0-9]+}}
// CHECK-ASM64: frinti v{{[0-9]+}}.2s, v{{[0-9]+}}.2s
// COMMONIR: ret <2 x float> [[VRNDI1_I]]
float32x2_t test_vrndi_f32(float32x2_t a) {
return vrndi_f32(a);
}
// COMMON-LABEL: test_vrndiq_f32
// COMMONIR: [[TMP0:%.*]] = bitcast <4 x float> %a to <16 x i8>
// UNCONSTRAINED: [[VRNDI1_I:%.*]] = call <4 x float> @llvm.nearbyint.v4f32(<4 x float> %a)
// CONSTRAINED: [[VRNDI1_I:%.*]] = call <4 x float> @llvm.experimental.constrained.nearbyint.v4f32(<4 x float> %a, metadata !"round.tonearest", metadata !"fpexcept.strict")
// CHECK-ASM32: vrintr.f32 s{{[0-9]+}}, s{{[0-9]+}}
// CHECK-ASM32: vrintr.f32 s{{[0-9]+}}, s{{[0-9]+}}
// CHECK-ASM32: vrintr.f32 s{{[0-9]+}}, s{{[0-9]+}}
// CHECK-ASM32: vrintr.f32 s{{[0-9]+}}, s{{[0-9]+}}
// CHECK-ASM64: frinti v{{[0-9]+}}.4s, v{{[0-9]+}}.4s
// COMMONIR: ret <4 x float> [[VRNDI1_I]]
float32x4_t test_vrndiq_f32(float32x4_t a) {
return vrndiq_f32(a);
}