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-mfpu.c

367 lines
19 KiB
C
Raw Normal View History

More tests for ARM FPU features. Also remove the svn:eol-style property from the test file. llvm-svn: 147947
2012-01-11 20:36:39 +08:00
// Test that different values of -mfpu pick correct ARM FPU target-feature(s).
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi %s -### -o %t.o 2>&1 \
More tests for ARM FPU features. Also remove the svn:eol-style property from the test file. llvm-svn: 147947
2012-01-11 20:36:39 +08:00
// RUN: | FileCheck --check-prefix=CHECK-DEFAULT %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
// CHECK-DEFAULT-NOT: "-target-feature" "+soft-float"
// CHECK-DEFAULT: "-target-feature" "+soft-float-abi"
More tests for ARM FPU features. Also remove the svn:eol-style property from the test file. llvm-svn: 147947
2012-01-11 20:36:39 +08:00
// CHECK-DEFAULT-NOT: "-target-feature" "+vfp2"
// CHECK-DEFAULT-NOT: "-target-feature" "+vfp3"
// CHECK-DEFAULT-NOT: "-target-feature" "+d16"
// CHECK-DEFAULT-NOT: "-target-feature" "+neon"
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=fpa %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-FPA %s
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=fpe2 %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-FPA %s
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=fpe3 %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-FPA %s
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=maverick %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-FPA %s
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-FPA: error: {{.*}} does not support '-mfpu={{fpa|fpe|fpe2|fpe3|maverick}}'
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfp %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-VFP %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 -mfpu=vfp %s -mfloat-abi=soft -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-2 %s
// CHECK-VFP-NOT: "-target-feature" "+soft-float"
// CHECK-VFP: "-target-feature" "+soft-float-abi"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// CHECK-VFP: "-target-feature" "+vfp2"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-VFP: "-target-feature" "-vfp3"
// CHECK-VFP: "-target-feature" "-vfp4"
// CHECK-VFP: "-target-feature" "-fp-armv8"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// CHECK-VFP: "-target-feature" "-neon"
[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
// CHECK-SOFT-ABI-FP-2: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP-2: "-target-feature" "-vfp3"
// CHECK-SOFT-ABI-FP-2: "-target-feature" "-vfp4"
// CHECK-SOFT-ABI-FP-2: "-target-feature" "-fp-armv8"
// CHECK-SOFT-ABI-FP-2: "-target-feature" "-neon"
// CHECK-SOFT-ABI-FP-2: "-target-feature" "-crypto"
// CHECK-SOFT-ABI-FP-2: "-target-feature" "-vfp2"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfp3 %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-VFP3 %s
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv3 %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-VFP3 %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 -mfpu=vfpv3 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-3 %s
// CHECK-VFP3-NOT: "-target-feature" "+soft-float"
// CHECK-VFP3: "-target-feature" "+soft-float-abi"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// CHECK-VFP3: "-target-feature" "+vfp3"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-VFP3: "-target-feature" "-vfp4"
// CHECK-VFP3: "-target-feature" "-fp-armv8"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// CHECK-VFP3: "-target-feature" "-neon"
[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
// CHECK-SOFT-ABI-FP-3: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP-3: "-target-feature" "-vfp2"
// CHECK-SOFT-ABI-FP-3: "-target-feature" "-vfp4"
// CHECK-SOFT-ABI-FP-3: "-target-feature" "-fp-armv8"
// CHECK-SOFT-ABI-FP-3: "-target-feature" "-neon"
// CHECK-SOFT-ABI-FP-3: "-target-feature" "-crypto"
// CHECK-SOFT-ABI-FP-3: "-target-feature" "-vfp3"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv3-fp16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP3-FP16 %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 -mfpu=vfpv3-fp16 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-3 %s
// CHECK-VFP3-FP16-NOT: "-target-feature" "+soft-float"
// CHECK-VFP3-FP16: "-target-feature" "+soft-float-abi"
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// CHECK-VFP3-FP16: "-target-feature" "-fp-only-sp"
// CHECK-VFP3-FP16: "-target-feature" "-d16"
// CHECK-VFP3-FP16: "-target-feature" "+vfp3"
// CHECK-VFP3-FP16: "-target-feature" "+fp16"
// CHECK-VFP3-FP16: "-target-feature" "-vfp4"
// CHECK-VFP3-FP16: "-target-feature" "-fp-armv8"
// CHECK-VFP3-FP16: "-target-feature" "-neon"
// CHECK-VFP3-FP16: "-target-feature" "-crypto"
Add -mfpu=neon-vfpv4 This enables user to architecturally specify ARMv7A + VFPv4 + NEON. Change-Id: I779b01fef5c47e5e4ac702ae24ed2f76a0e4c63f llvm-svn: 222932
2014-11-29 04:39:54 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfp3-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP3-D16 %s
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv3-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP3-D16 %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 -mfpu=vfpv3-d16 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-3 %s
// CHECK-VFP3-D16-NOT: "-target-feature" "+soft-float"
// CHECK-VFP3-D16: "-target-feature" "+soft-float-abi"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-VFP3-D16: "-target-feature" "-fp-only-sp"
Add -mfpu=neon-vfpv4 This enables user to architecturally specify ARMv7A + VFPv4 + NEON. Change-Id: I779b01fef5c47e5e4ac702ae24ed2f76a0e4c63f llvm-svn: 222932
2014-11-29 04:39:54 +08:00
// CHECK-VFP3-D16: "-target-feature" "+d16"
Using ARMTargetParser in Clang This is a starting point for using the TargetParser in Clang, in a simple enough part of the code that can be used without disrupting the crazy platform support that we need to be compatible with other toolchains. Also adding a few FIXME on obvious places that need replacing, but those cases will indeed break a few of the platform assumptions, as arch/cpu names change multiple times in the driver. Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since -mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option string is still supported as an alias to "neon". llvm-svn: 236901
2015-05-09 05:04:50 +08:00
// CHECK-VFP3-D16: "-target-feature" "+vfp3"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-VFP3-D16: "-target-feature" "-vfp4"
// CHECK-VFP3-D16: "-target-feature" "-fp-armv8"
Add -mfpu=neon-vfpv4 This enables user to architecturally specify ARMv7A + VFPv4 + NEON. Change-Id: I779b01fef5c47e5e4ac702ae24ed2f76a0e4c63f llvm-svn: 222932
2014-11-29 04:39:54 +08:00
// CHECK-VFP3-D16: "-target-feature" "-neon"
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv3-d16-fp16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP3-D16-FP16 %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 -mfpu=vfpv3-d16-fp16 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-3 %s
// CHECK-VFP3-D16-FP16-NOT: "-target-feature" "+soft-float"
// CHECK-VFP3-D16-FP16: "-target-feature" "+soft-float-abi"
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// CHECK-VFP3-D16-FP16: "-target-feature" "-fp-only-sp"
// CHECK-VFP3-D16-FP16: "-target-feature" "+d16"
// CHECK-VFP3-D16-FP16: "-target-feature" "+vfp3"
// CHECK-VFP3-D16-FP16: "-target-feature" "+fp16"
// CHECK-VFP3-D16-FP16: "-target-feature" "-vfp4"
// CHECK-VFP3-D16-FP16: "-target-feature" "-fp-armv8"
// CHECK-VFP3-D16-FP16: "-target-feature" "-neon"
// CHECK-VFP3-D16-FP16: "-target-feature" "-crypto"
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv3xd %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP3XD %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 -mfpu=vfpv3xd -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-3 %s
// CHECK-VFP3XD-NOT: "-target-feature" "+soft-float"
// CHECK-VFP3XD: "-target-feature" "+soft-float-abi"
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// CHECK-VFP3XD: "-target-feature" "+fp-only-sp"
// CHECK-VFP3XD: "-target-feature" "+d16"
// CHECK-VFP3XD: "-target-feature" "+vfp3"
// CHECK-VFP3XD: "-target-feature" "-fp16"
// CHECK-VFP3XD: "-target-feature" "-vfp4"
// CHECK-VFP3XD: "-target-feature" "-fp-armv8"
// CHECK-VFP3XD: "-target-feature" "-neon"
// CHECK-VFP3XD: "-target-feature" "-crypto"
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv3xd-fp16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP3XD-FP16 %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 -mfpu=vfpv3xd-fp16 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-3 %s
// CHECK-VFP3XD-FP16-NOT: "-target-feature" "+soft-float"
// CHECK-VFP3XD-FP16: "-target-feature" "+soft-float-abi"
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// CHECK-VFP3XD-FP16: "-target-feature" "+fp-only-sp"
// CHECK-VFP3XD-FP16: "-target-feature" "+d16"
// CHECK-VFP3XD-FP16: "-target-feature" "+vfp3"
// CHECK-VFP3XD-FP16: "-target-feature" "+fp16"
// CHECK-VFP3XD-FP16: "-target-feature" "-vfp4"
// CHECK-VFP3XD-FP16: "-target-feature" "-fp-armv8"
// CHECK-VFP3XD-FP16: "-target-feature" "-neon"
// CHECK-VFP3XD-FP16: "-target-feature" "-crypto"
[ARM] add basic support for Cortex-A7 and VFPv4 to Clang llvm-svn: 195359
2013-11-21 22:04:38 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfp4 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP4 %s
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv4 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP4 %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 -mfpu=vfpv4 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-4 %s
// CHECK-VFP4-NOT: "-target-feature" "+soft-float"
// CHECK-VFP4: "-target-feature" "+soft-float-abi"
[ARM] add basic support for Cortex-A7 and VFPv4 to Clang llvm-svn: 195359
2013-11-21 22:04:38 +08:00
// CHECK-VFP4: "-target-feature" "+vfp4"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-VFP4: "-target-feature" "-fp-armv8"
[ARM] add basic support for Cortex-A7 and VFPv4 to Clang llvm-svn: 195359
2013-11-21 22:04:38 +08:00
// CHECK-VFP4: "-target-feature" "-neon"
[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
// CHECK-SOFT-ABI-FP-4: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP-4: "-target-feature" "-vfp2"
// CHECK-SOFT-ABI-FP-4: "-target-feature" "-vfp3"
// CHECK-SOFT-ABI-FP-4: "-target-feature" "-fp-armv8"
// CHECK-SOFT-ABI-FP-4: "-target-feature" "-neon"
// CHECK-SOFT-ABI-FP-4: "-target-feature" "-crypto"
// CHECK-SOFT-ABI-FP-4: "-target-feature" "-vfp4"
[ARM] add basic support for Cortex-A7 and VFPv4 to Clang llvm-svn: 195359
2013-11-21 22:04:38 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=vfp4-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP4-D16 %s
// RUN: %clang -target arm-linux-eabi -mfpu=vfpv4-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-VFP4-D16 %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 -mfpu=vfpv4-d16 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-4 %s
// CHECK-VFP4-D16-NOT: "-target-feature" "+soft-float"
// CHECK-VFP4-D16: "-target-feature" "+soft-float-abi"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-VFP4-D16: "-target-feature" "-fp-only-sp"
[ARM] add basic support for Cortex-A7 and VFPv4 to Clang llvm-svn: 195359
2013-11-21 22:04:38 +08:00
// CHECK-VFP4-D16: "-target-feature" "+d16"
Using ARMTargetParser in Clang This is a starting point for using the TargetParser in Clang, in a simple enough part of the code that can be used without disrupting the crazy platform support that we need to be compatible with other toolchains. Also adding a few FIXME on obvious places that need replacing, but those cases will indeed break a few of the platform assumptions, as arch/cpu names change multiple times in the driver. Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since -mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option string is still supported as an alias to "neon". llvm-svn: 236901
2015-05-09 05:04:50 +08:00
// CHECK-VFP4-D16: "-target-feature" "+vfp4"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-VFP4-D16: "-target-feature" "-fp-armv8"
[ARM] add basic support for Cortex-A7 and VFPv4 to Clang llvm-svn: 195359
2013-11-21 22:04:38 +08:00
// CHECK-VFP4-D16: "-target-feature" "-neon"
Add support for FPv4-SP to the clang driver Added two new options for -mfpu when targetting ARM: * fpv4-sp-d16 * fp4-sp-d16 The first is the same spelling as gcc. The lack of a leading `v' is correct, this is consistent with ARM's documentation and gcc's spelling of the option. llvm-svn: 201846
2014-02-21 18:39:15 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=fp4-sp-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FP4-SP-D16 %s
// RUN: %clang -target arm-linux-eabi -mfpu=fpv4-sp-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FP4-SP-D16 %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 -mfpu=fpv4-sp-d16 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-4 %s
// CHECK-FP4-SP-D16-NOT: "-target-feature" "+soft-float"
// CHECK-FP4-SP-D16: "-target-feature" "+soft-float-abi"
Add support for FPv4-SP to the clang driver Added two new options for -mfpu when targetting ARM: * fpv4-sp-d16 * fp4-sp-d16 The first is the same spelling as gcc. The lack of a leading `v' is correct, this is consistent with ARM's documentation and gcc's spelling of the option. llvm-svn: 201846
2014-02-21 18:39:15 +08:00
// CHECK-FP4-SP-D16: "-target-feature" "+fp-only-sp"
Using ARMTargetParser in Clang This is a starting point for using the TargetParser in Clang, in a simple enough part of the code that can be used without disrupting the crazy platform support that we need to be compatible with other toolchains. Also adding a few FIXME on obvious places that need replacing, but those cases will indeed break a few of the platform assumptions, as arch/cpu names change multiple times in the driver. Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since -mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option string is still supported as an alias to "neon". llvm-svn: 236901
2015-05-09 05:04:50 +08:00
// CHECK-FP4-SP-D16: "-target-feature" "+d16"
// CHECK-FP4-SP-D16: "-target-feature" "+vfp4"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-FP4-SP-D16: "-target-feature" "-fp-armv8"
Add support for FPv4-SP to the clang driver Added two new options for -mfpu when targetting ARM: * fpv4-sp-d16 * fp4-sp-d16 The first is the same spelling as gcc. The lack of a leading `v' is correct, this is consistent with ARM's documentation and gcc's spelling of the option. llvm-svn: 201846
2014-02-21 18:39:15 +08:00
// CHECK-FP4-SP-D16: "-target-feature" "-neon"
[ARM] add basic support for Cortex-A7 and VFPv4 to Clang llvm-svn: 195359
2013-11-21 22:04:38 +08:00
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
2014-10-01 17:03:02 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=fp5-sp-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FP5-SP-D16 %s
// RUN: %clang -target arm-linux-eabi -mfpu=fpv5-sp-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FP5-SP-D16 %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 -mfpu=fp-armv8-sp-d16 -mfloat-abi=soft %s -### -o %t.o \
// RUN: 2>&1 | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// CHECK-FP5-SP-D16-NOT: "-target-feature" "+soft-float"
// CHECK-FP5-SP-D16: "-target-feature" "+soft-float-abi"
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
2014-10-01 17:03:02 +08:00
// CHECK-FP5-SP-D16: "-target-feature" "+fp-only-sp"
// CHECK-FP5-SP-D16: "-target-feature" "+d16"
Using ARMTargetParser in Clang This is a starting point for using the TargetParser in Clang, in a simple enough part of the code that can be used without disrupting the crazy platform support that we need to be compatible with other toolchains. Also adding a few FIXME on obvious places that need replacing, but those cases will indeed break a few of the platform assumptions, as arch/cpu names change multiple times in the driver. Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since -mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option string is still supported as an alias to "neon". llvm-svn: 236901
2015-05-09 05:04:50 +08:00
// CHECK-FP5-SP-D16: "-target-feature" "+fp-armv8"
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
2014-10-01 17:03:02 +08:00
// CHECK-FP5-SP-D16: "-target-feature" "-neon"
// CHECK-FP5-SP-D16: "-target-feature" "-crypto"
// RUN: %clang -target arm-linux-eabi -mfpu=fp5-dp-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FP5-DP-D16 %s
// RUN: %clang -target arm-linux-eabi -mfpu=fpv5-dp-d16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FP5-DP-D16 %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 -mfpu=fpv5-dp-d16 %s -mfloat-abi=soft -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-5 %s
// CHECK-FP5-DP-D16-NOT: "-target-feature" "+soft-float"
// CHECK-FP5-DP-D16: "-target-feature" "+soft-float-abi"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-FP5-DP-D16: "-target-feature" "-fp-only-sp"
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
2014-10-01 17:03:02 +08:00
// CHECK-FP5-DP-D16: "-target-feature" "+d16"
Using ARMTargetParser in Clang This is a starting point for using the TargetParser in Clang, in a simple enough part of the code that can be used without disrupting the crazy platform support that we need to be compatible with other toolchains. Also adding a few FIXME on obvious places that need replacing, but those cases will indeed break a few of the platform assumptions, as arch/cpu names change multiple times in the driver. Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since -mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option string is still supported as an alias to "neon". llvm-svn: 236901
2015-05-09 05:04:50 +08:00
// CHECK-FP5-DP-D16: "-target-feature" "+fp-armv8"
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
2014-10-01 17:03:02 +08:00
// CHECK-FP5-DP-D16: "-target-feature" "-neon"
// CHECK-FP5-DP-D16: "-target-feature" "-crypto"
[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
// CHECK-SOFT-ABI-FP-5: "-target-feature" "+soft-float"
// CHECK-SOFT-ABI-FP-5: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP-5: "-target-feature" "-vfp2"
// CHECK-SOFT-ABI-FP-5: "-target-feature" "-vfp3"
// CHECK-SOFT-ABI-FP-5: "-target-feature" "-vfp4"
// CHECK-SOFT-ABI-FP-5: "-target-feature" "-neon"
// CHECK-SOFT-ABI-FP-5: "-target-feature" "-crypto"
// CHECK-SOFT-ABI-FP-5: "-target-feature" "-fp-armv8"
[ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DP The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be modeled using the same target feature, and all double-precision operations are already disabled by the fp-only-sp target features. llvm-svn: 218748
2014-10-01 17:03:02 +08:00
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=neon %s -### -o %t.o 2>&1 \
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// RUN: | FileCheck --check-prefix=CHECK-NEON %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 -mfpu=neon -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-6 %s
// CHECK-NEON-NOT: "-target-feature" "+soft-float"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
// CHECK-NEON: "-target-feature" "+neon"
[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
// CHECK-SOFT-ABI-FP-6: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP-6: "-target-feature" "-vfp2"
// CHECK-SOFT-ABI-FP-6: "-target-feature" "-vfp4"
// CHECK-SOFT-ABI-FP-6: "-target-feature" "-fp-armv8"
// CHECK-SOFT-ABI-FP-6: "-target-feature" "-crypto"
// CHECK-SOFT-ABI-FP-6: "-target-feature" "-vfp3"
// CHECK-SOFT-ABI-FP-6: "-target-feature" "-neon"
Fix -mfpu parsing on ARM. - Support gcc-compatible vfpv3 name in addition to vfp3. - Support vfpv3-d16. - Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions for those!). llvm-svn: 147943
2012-01-11 19:21:31 +08:00
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=neon-fp16 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NEON-FP16 %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 -mfpu=neon-fp16 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-6 %s
// CHECK-NEON-FP16-NOT: "-target-feature" "+soft-float"
// CHECK-NEON-FP16: "-target-feature" "+soft-float-abi"
[ARM]: Extend -mfpu options for half-precision and vfpv3xd Some of the the permissible ARM -mfpu options, which are supported in GCC, are currently not present in llvm/clang.This patch adds the options: 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These are related to half-precision floating-point and single precision. Reviewers: rengolin, ranjeet.singh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10764 llvm-svn: 240929
2015-06-29 17:30:19 +08:00
// CHECK-NEON-FP16: "-target-feature" "-fp-only-sp"
// CHECK-NEON-FP16: "-target-feature" "-d16"
// CHECK-NEON-FP16: "-target-feature" "+vfp3"
// CHECK-NEON-FP16: "-target-feature" "+fp16"
// CHECK-NEON-FP16: "-target-feature" "-vfp4"
// CHECK-NEON-FP16: "-target-feature" "-fp-armv8"
// CHECK-NEON-FP16: "-target-feature" "+neon"
// CHECK-NEON-FP16: "-target-feature" "-crypto"
Add additional arguments for -mfpu options Add neon-vfpv3 to allow specifying both at the same time. This is not an option that GCC supports, but follows the same track and should be non-controversial. Change-Id: Id9ec157c835937d7d11ad0f49dbe5171fac17658 llvm-svn: 222933
2014-11-29 04:39:59 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=neon-vfpv3 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NEON-VFPV3 %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 -mfpu=neon-vfpv3 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-6 %s
// CHECK-NEON-VFPV3-NOT: "-target-feature" "+soft-float"
// CHECK-NEON-VFPV3: "-target-feature" "+soft-float-abi"
// CHECK-NEON-VFPV3: "-target-feature" "+vfp3"
Add additional arguments for -mfpu options Add neon-vfpv3 to allow specifying both at the same time. This is not an option that GCC supports, but follows the same track and should be non-controversial. Change-Id: Id9ec157c835937d7d11ad0f49dbe5171fac17658 llvm-svn: 222933
2014-11-29 04:39:59 +08:00
// CHECK-NEON-VFPV3: "-target-feature" "+neon"
Add -mfpu=neon-vfpv4 This enables user to architecturally specify ARMv7A + VFPv4 + NEON. Change-Id: I779b01fef5c47e5e4ac702ae24ed2f76a0e4c63f llvm-svn: 222932
2014-11-29 04:39:54 +08:00
// RUN: %clang -target arm-linux-eabi -mfpu=neon-vfpv4 %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NEON-VFPV4 %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 -mfpu=neon-vfpv4 -mfloat-abi=soft %s -### -o %t.o 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-7 %s
// CHECK-NEON-VFPV4-NOT: "-target-feature" "+soft-float"
// CHECK-NEON-VFPV4: "-target-feature" "+soft-float-abi"
Correction to -mfu=neon-vfpv4 to pass the correct backend feature name Change-Id: I4dbfe1d97670fc4e626368ef1f91fc008778dfca llvm-svn: 224523
2014-12-19 00:31:18 +08:00
// CHECK-NEON-VFPV4: "-target-feature" "+vfp4"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-NEON-VFPV4: "-target-feature" "+neon"
[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
// CHECK-SOFT-ABI-FP-7: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP-7: "-target-feature" "-vfp2"
// CHECK-SOFT-ABI-FP-7: "-target-feature" "-vfp3"
// CHECK-SOFT-ABI-FP-7: "-target-feature" "-fp-armv8"
// CHECK-SOFT-ABI-FP-7: "-target-feature" "-crypto"
// CHECK-SOFT-ABI-FP-7: "-target-feature" "-vfp4"
// CHECK-SOFT-ABI-FP-7: "-target-feature" "-neon"
Add -mfpu=neon-vfpv4 This enables user to architecturally specify ARMv7A + VFPv4 + NEON. Change-Id: I779b01fef5c47e5e4ac702ae24ed2f76a0e4c63f llvm-svn: 222932
2014-11-29 04:39:54 +08:00
rename -ccc-host-triple into -target llvm-svn: 148582
2012-01-21 06:01:23 +08:00
// RUN: %clang -target arm-linux-eabi -msoft-float %s -### -o %t.o 2>&1 \
[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: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
[ARM] Fix NEON wrongly being enabled with soft-float when targeting armv8/Cortex-A53/A57. This was caused by r200708 which enabled the crypto feature for these cores. llvm-svn: 201223
2014-02-12 18:22:35 +08:00
// RUN: %clang -target armv8 %s -### 2>&1 \
[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: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv8a -mfpu=neon %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP-8 %s
// CHECK-SOFT-ABI-FP-8: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP-8: "-target-feature" "-vfp2"
// CHECK-SOFT-ABI-FP-8: "-target-feature" "-vfp4"
// CHECK-SOFT-ABI-FP-8: "-target-feature" "-fp-armv8"
// CHECK-SOFT-ABI-FP-8: "-target-feature" "-crypto"
// CHECK-SOFT-ABI-FP-8: "-target-feature" "-vfp3"
// CHECK-SOFT-ABI-FP-8: "-target-feature" "-neon"
[ARM] Fix NEON wrongly being enabled with soft-float when targeting armv8/Cortex-A53/A57. This was caused by r200708 which enabled the crypto feature for these cores. llvm-svn: 201223
2014-02-12 18:22:35 +08:00
Add driver support for FP, SIMD and crypto defaults. Although we wire up a bit for v8fp for macro setting purposes, we don't set a macro yet. Need to ask list about that. Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0 llvm-svn: 193367
2013-10-25 02:32:51 +08:00
// RUN: %clang -target armv8 -mfpu=fp-armv8 %s -### 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-ARMV8-SOFT-FLOAT %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
// CHECK-ARMV8-SOFT-FLOAT: "-target-feature" "+soft-float"
// CHECK-ARMV8-SOFT-FLOAT: "-target-feature" "+soft-float-abi"
// NOT-CHECK-ARMV8-SOFT-FLOAT: "-target-feature" "+fp-armv8"
// CHECK-ARMV9-SOFT-FLOAT: "-target-feature" "-neon"
[ARM] Fix NEON wrongly being enabled with soft-float when targeting armv8/Cortex-A53/A57. This was caused by r200708 which enabled the crypto feature for these cores. llvm-svn: 201223
2014-02-12 18:22:35 +08:00
// CHECK-ARMV8-SOFT-FLOAT: "-target-feature" "-crypto"
Add driver support for FP, SIMD and crypto defaults. Although we wire up a bit for v8fp for macro setting purposes, we don't set a macro yet. Need to ask list about that. Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0 llvm-svn: 193367
2013-10-25 02:32:51 +08:00
Add support for passing v8fp options via -mfpu. llvm-svn: 185075
2013-06-27 21:19:54 +08:00
// RUN: %clang -target armv8-linux-gnueabihf -mfpu=fp-armv8 %s -### 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-FP-ARMV8 %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
// CHECK-FP-ARMV8-NOT: "-target-feature" "+soft-float"
// CHECK-FP-ARMV8-NOT: "-target-feature" "+soft-float-abi"
[ARMv8] Change the naming of some options to be more consistent. Clang side changes for LLVM r190692. llvm-svn: 190693
2013-09-13 21:48:33 +08:00
// CHECK-FP-ARMV8: "-target-feature" "+fp-armv8"
Add driver support for FP, SIMD and crypto defaults. Although we wire up a bit for v8fp for macro setting purposes, we don't set a macro yet. Need to ask list about that. Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0 llvm-svn: 193367
2013-10-25 02:32:51 +08:00
// CHECK-FP-ARMV8: "-target-feature" "-neon"
// CHECK-FP-ARMV8: "-target-feature" "-crypto"
Add support for passing v8fp options via -mfpu. llvm-svn: 185075
2013-06-27 21:19:54 +08:00
// RUN: %clang -target armv8-linux-gnueabihf -mfpu=neon-fp-armv8 %s -### 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NEON-FP-ARMV8 %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
// CHECK-NEON-FP-ARMV8-NOT: "-target-feature" "+soft-float"
// CHECK-NEON-FP-ARMV8-NOT: "-target-feature" "+soft-float-abi"
[ARMv8] Change the naming of some options to be more consistent. Clang side changes for LLVM r190692. llvm-svn: 190693
2013-09-13 21:48:33 +08:00
// CHECK-NEON-FP-ARMV8: "-target-feature" "+fp-armv8"
Add support for passing v8fp options via -mfpu. llvm-svn: 185075
2013-06-27 21:19:54 +08:00
// CHECK-NEON-FP-ARMV8: "-target-feature" "+neon"
Add driver support for FP, SIMD and crypto defaults. Although we wire up a bit for v8fp for macro setting purposes, we don't set a macro yet. Need to ask list about that. Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0 llvm-svn: 193367
2013-10-25 02:32:51 +08:00
// CHECK-NEON-FP-ARMV8: "-target-feature" "-crypto"
ARM: add test for last commit This time I managed to forget the test. Patch still by Stephen Kelly. llvm-svn: 188797
2013-08-20 21:19:43 +08:00
[ARMv8] Add crypto-neon-fp-armv8 -mfpu option in driver. llvm-svn: 191001
2013-09-19 21:54:03 +08:00
// RUN: %clang -target armv8-linux-gnueabihf -mfpu=crypto-neon-fp-armv8 %s -### 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRYPTO-NEON-FP-ARMV8 %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
// CHECK-CRYPTO-NEON-FP-ARMV8-NOT: "-target-feature" "+soft-float"
// CHECK-CRYPTO-NEON-FP-ARMV8-NOT: "-target-feature" "+soft-float-abi"
[ARMv8] Add crypto-neon-fp-armv8 -mfpu option in driver. llvm-svn: 191001
2013-09-19 21:54:03 +08:00
// CHECK-CRYPTO-NEON-FP-ARMV8: "-target-feature" "+fp-armv8"
Add driver support for FP, SIMD and crypto defaults. Although we wire up a bit for v8fp for macro setting purposes, we don't set a macro yet. Need to ask list about that. Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0 llvm-svn: 193367
2013-10-25 02:32:51 +08:00
// CHECK-CRYPTO-NEON-FP-ARMV8: "-target-feature" "+crypto"
[ARMv8] Add crypto-neon-fp-armv8 -mfpu option in driver. llvm-svn: 191001
2013-09-19 21:54:03 +08:00
[ARM] Add -mfpu=none option to the driver. llvm-svn: 191736
2013-10-01 18:20:54 +08:00
// RUN: %clang -target armv8-linux-gnueabi -mfpu=none %s -### 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NO-FP %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
// CHECK-NO-FP-NOT: "-target-feature" "+soft-float"
// CHECK-NO-FP: "-target-feature" "+soft-float-abi"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-NO-FP: "-target-feature" "-fp-only-sp"
// CHECK-NO-FP: "-target-feature" "-d16"
[ARM] Add -mfpu=none option to the driver. llvm-svn: 191736
2013-10-01 18:20:54 +08:00
// CHECK-NO-FP: "-target-feature" "-vfp2"
// CHECK-NO-FP: "-target-feature" "-vfp3"
// CHECK-NO-FP: "-target-feature" "-vfp4"
// CHECK-NO-FP: "-target-feature" "-fp-armv8"
Revert changes in r218863, r218864 Summary: The changes introduced in the above two commits are giving a rough time to one of the build bots. Reverting the changes for the moment so that the bot can go green again. Change-Id: Id19f6cb2a8bc292631fac2262268927563d820c2 llvm-svn: 218970
2014-10-03 17:11:41 +08:00
// CHECK-NO-FP: "-target-feature" "-neon"
[ARM] Use TargetParser to determine FPU subtarget features The main effect of this is to fix anomalies where certain -mfpu options didn't disable everything that they should causing strange behaviour when combined with -mcpu or -march values that themselves enabled fpu subtarget features, e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as -mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled. Invalid -mfpu options now also give an error, which is consistent with the handling of the .fpu directive. Differential Revision: http://reviews.llvm.org/D10239 llvm-svn: 239152
2015-06-05 21:34:11 +08:00
// CHECK-NO-FP: "-target-feature" "-crypto"
[ARM] Add -mfpu=none option to the driver. llvm-svn: 191736
2013-10-01 18:20:54 +08:00
ARM: add test for last commit This time I managed to forget the test. Patch still by Stephen Kelly. llvm-svn: 188797
2013-08-20 21:19:43 +08:00
// RUN: %clang -target arm-linux-gnueabihf %s -### 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-HF %s
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273735
2016-06-25 05:35:06 +08:00
// RUN: %clang -target arm-linux-musleabihf %s -### 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-HF %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
// CHECK-HF-NOT: "-target-feature" "+soft-float"
// CHECK-HF-NOT: "-target-feature" "+soft-float-abi"
[ARM] Add support for ARMV6K subtarget (Clang) ARMv6K is another layer between ARMV6 and ARMV6T2. This is the Clang side of the changes. ARMV6 family LLVM implementation. +-------------------------------------+ | ARMV6 | +----------------+--------------------+ | ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors +----------------+--------------------+ have support for hint instructions | ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can +-------------------------------------+ be either real or default to NOP. | ARMV7 (arm,thumb,thumb2) | The two processors also use +-------------------------------------+ different encoding for them. Patch by Vinicius Tinti. llvm-svn: 232469
2015-03-17 19:55:43 +08:00
// CHECK-HF: "-target-cpu" "arm1176jzf-s"
Don't pass +soft-float, +soft-float-abi to the arm assembler. llvm-svn: 195551
2013-11-23 22:36:40 +08:00
// RUN: %clang -target armv7-apple-darwin -x assembler %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=ASM %s
// ASM-NOT: -target-feature
[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 armv8-linux-gnueabi -mfloat-abi=soft -mfpu=none %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv7-linux-gnueabi -mfloat-abi=soft -mfpu=none %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv6-linux-gnueabi -mfloat-abi=soft -mfpu=none %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv5-linux-gnueabi -mfloat-abi=soft -mfpu=none %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv4-linux-gnueabi -mfloat-abi=soft -mfpu=none %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv8-linux-gnueabi -msoft-float -mfpu=none %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv8-linux-gnueabi -mfloat-abi=soft %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// RUN: %clang -target armv8-linux-gnueabi -msoft-float %s -### -c 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-SOFT-ABI-FP %s
// CHECK-SOFT-ABI-FP: "-target-feature" "+soft-float"
// CHECK-SOFT-ABI-FP: "-target-feature" "+soft-float-abi"
// CHECK-SOFT-ABI-FP: "-target-feature" "-vfp2"
// CHECK-SOFT-ABI-FP: "-target-feature" "-vfp3"
// CHECK-SOFT-ABI-FP: "-target-feature" "-vfp4"
// CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
// CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
// CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"