maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/arm-dotprod.c

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

31 lines
1.8 KiB
C
Raw Normal View History

[ARM][AArch64] Cortex-A75 and Cortex-A55 tests Add frontend tests for Cortex-A75 and Cortex-A55, Arm's latest big.LITTLE A-class cores. They implement the ARMv8.2-A architecture, including the cryptography and RAS extensions, plus the optional dot product extension. They also implement the RCpc AArch64 extension from ARMv8.3-A. Cortex-A75: https://developer.arm.com/products/processors/cortex-a/cortex-a75 Cortex-A55: https://developer.arm.com/products/processors/cortex-a/cortex-a55 Differential Revision: https://reviews.llvm.org/D36731 llvm-svn: 311319
2017-08-21 16:52:45 +08:00
// RUN: %clang -### -target arm %s 2>&1 | FileCheck %s --check-prefix=CHECK-NONE
// RUN: %clang -### -target arm -march=armv8.1a %s 2>&1 | FileCheck %s --check-prefix=CHECK-NONE
// RUN: %clang -### -target arm -march=armv8.2a %s 2>&1 | FileCheck %s --check-prefix=CHECK-NONE
// RUN: %clang -### -target arm -march=armv8.3a %s 2>&1 | FileCheck %s --check-prefix=CHECK-NONE
// CHECK-NONE-NOT: "-target-feature" "+dotprod"
[ARM] disable FPU features when using soft floating point. To be compatible with GCC if soft floating point is in effect any FPU specified is effectively ignored, eg, -mfloat-abi=soft -fpu=neon If any floating point features which require FPU hardware are enabled they must be disable. There was some support for doing this for NEON, but it did not handle VFP, nor did it prevent the backend from emitting the build attribute Tag_FP_arch describing the generated code as using the floating point hardware if a FPU was specified (even though soft float does not use the FPU). Disabling the hardware floating point features for targets which are compiling for soft float has meant that some tests which were incorrectly checking for hardware support also needed to be updated. In such cases, where appropriate the tests have been updated to check compiling for soft float and a non-soft float variant (usually softfp). This was usually because the target specified in the test defaulted to soft float. Differential Revision: https://reviews.llvm.org/D42569 llvm-svn: 325492
2018-02-19 20:40:26 +08:00
// RUN: %clang -### -target arm-linux-eabi -march=armv8.2a+dotprod %s 2>&1 | FileCheck %s
// RUN: %clang -### -target arm-linux-eabi -march=armv8.3a+dotprod %s 2>&1 | FileCheck %s
// RUN: %clang -### -target arm-linux-eabi -mcpu=cortex-a75 %s 2>&1 | FileCheck %s
[AArch64] Add support for Cortex-A76 and Cortex-A76AE - Add LLVM backend support for Cortex-A76 and Cortex-A76AE - Documentation can be found at https://developer.arm.com/products/processors/cortex-a/cortex-a76 Differential Revision: https://reviews.llvm.org/D57764 llvm-svn: 354789
2019-02-25 23:11:31 +08:00
// RUN: %clang -### -target arm-linux-eabi -mcpu=cortex-a76 %s 2>&1 | FileCheck %s
// RUN: %clang -### -target arm-linux-eabi -mcpu=cortex-a76ae %s 2>&1 | FileCheck %s
[ARM] disable FPU features when using soft floating point. To be compatible with GCC if soft floating point is in effect any FPU specified is effectively ignored, eg, -mfloat-abi=soft -fpu=neon If any floating point features which require FPU hardware are enabled they must be disable. There was some support for doing this for NEON, but it did not handle VFP, nor did it prevent the backend from emitting the build attribute Tag_FP_arch describing the generated code as using the floating point hardware if a FPU was specified (even though soft float does not use the FPU). Disabling the hardware floating point features for targets which are compiling for soft float has meant that some tests which were incorrectly checking for hardware support also needed to be updated. In such cases, where appropriate the tests have been updated to check compiling for soft float and a non-soft float variant (usually softfp). This was usually because the target specified in the test defaulted to soft float. Differential Revision: https://reviews.llvm.org/D42569 llvm-svn: 325492
2018-02-19 20:40:26 +08:00
// RUN: %clang -### -target arm-linux-eabi -mcpu=cortex-a55 %s 2>&1 | FileCheck %s
[ARM][AArch64] Cortex-A75 and Cortex-A55 tests Add frontend tests for Cortex-A75 and Cortex-A55, Arm's latest big.LITTLE A-class cores. They implement the ARMv8.2-A architecture, including the cryptography and RAS extensions, plus the optional dot product extension. They also implement the RCpc AArch64 extension from ARMv8.3-A. Cortex-A75: https://developer.arm.com/products/processors/cortex-a/cortex-a75 Cortex-A55: https://developer.arm.com/products/processors/cortex-a/cortex-a55 Differential Revision: https://reviews.llvm.org/D36731 llvm-svn: 311319
2017-08-21 16:52:45 +08:00
// CHECK: "+dotprod"
[ARM] disable FPU features when using soft floating point. To be compatible with GCC if soft floating point is in effect any FPU specified is effectively ignored, eg, -mfloat-abi=soft -fpu=neon If any floating point features which require FPU hardware are enabled they must be disable. There was some support for doing this for NEON, but it did not handle VFP, nor did it prevent the backend from emitting the build attribute Tag_FP_arch describing the generated code as using the floating point hardware if a FPU was specified (even though soft float does not use the FPU). Disabling the hardware floating point features for targets which are compiling for soft float has meant that some tests which were incorrectly checking for hardware support also needed to be updated. In such cases, where appropriate the tests have been updated to check compiling for soft float and a non-soft float variant (usually softfp). This was usually because the target specified in the test defaulted to soft float. Differential Revision: https://reviews.llvm.org/D42569 llvm-svn: 325492
2018-02-19 20:40:26 +08:00
// The following default to -msoft-float
// RUN: %clang -### -target arm -march=armv8.2a+dotprod %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-DOTPROD
// RUN: %clang -### -target arm -march=armv8.3a+dotprod %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-DOTPROD
// RUN: %clang -### -target arm -mcpu=cortex-a75 %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-DOTPROD
[AArch64] Add support for Cortex-A76 and Cortex-A76AE - Add LLVM backend support for Cortex-A76 and Cortex-A76AE - Documentation can be found at https://developer.arm.com/products/processors/cortex-a/cortex-a76 Differential Revision: https://reviews.llvm.org/D57764 llvm-svn: 354789
2019-02-25 23:11:31 +08:00
// RUN: %clang -### -target arm -mcpu=cortex-a76 %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-DOTPROD
// RUN: %clang -### -target arm -mcpu=cortex-a76ae %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-DOTPROD
[ARM] disable FPU features when using soft floating point. To be compatible with GCC if soft floating point is in effect any FPU specified is effectively ignored, eg, -mfloat-abi=soft -fpu=neon If any floating point features which require FPU hardware are enabled they must be disable. There was some support for doing this for NEON, but it did not handle VFP, nor did it prevent the backend from emitting the build attribute Tag_FP_arch describing the generated code as using the floating point hardware if a FPU was specified (even though soft float does not use the FPU). Disabling the hardware floating point features for targets which are compiling for soft float has meant that some tests which were incorrectly checking for hardware support also needed to be updated. In such cases, where appropriate the tests have been updated to check compiling for soft float and a non-soft float variant (usually softfp). This was usually because the target specified in the test defaulted to soft float. Differential Revision: https://reviews.llvm.org/D42569 llvm-svn: 325492
2018-02-19 20:40:26 +08:00
// RUN: %clang -### -target arm -mcpu=cortex-a55 %s 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-DOTPROD
// We rely on the backend disabling dotprod as it depends on neon, so check that
// neon is disabled after the dotprod was enabled.
// CHECK-NO-DOTPROD-NOT: "+dotprod"