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

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

114 lines
9.3 KiB
C
Raw Normal View History

ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
// REQUIRES: arm-registered-target
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a8 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP3: "target-features"="+armv7-a,+d32,+dsp,+fp64,+neon,+thumb-mode,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp"
Refactoring of how ARMTargetInfo handles default target features. Differential Revision: http://reviews.llvm.org/D11299 llvm-svn: 246946
2015-09-07 00:15:45 +08:00
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a5 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP4: "target-features"="+armv7-a,+d32,+dsp,+fp16,+fp64,+neon,+thumb-mode,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp,+vfp4,+vfp4d16,+vfp4d16sp,+vfp4sp"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a7 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-a12 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
[ARM] Compute a target feature which corresponds to the ARM version. Currently, the interaction between the triple, the CPU, and the supported features is a mess: the driver edits the triple to indicate the supported architecture version, and the LLVM backend uses this to figure out what instructions are legal. This makes it difficult to understand what's happening, and makes it impossible to LTO together two modules with different computed architectures. Instead of relying on triple rewriting to get the correct target features, we should add the right target features explicitly. Differential Revision: https://reviews.llvm.org/D45240 llvm-svn: 330169
2018-04-17 07:52:58 +08:00
// RUN: %clang_cc1 -triple thumbv7s-linux-gnueabi -target-cpu swift -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV-2
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu krait -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP4-DIV: "target-features"="+armv7-a,+d32,+dsp,+fp16,+fp64,+hwdiv,+hwdiv-arm,+neon,+thumb-mode,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp,+vfp4,+vfp4d16,+vfp4d16sp,+vfp4sp"
// CHECK-VFP4-DIV-2: "target-features"="+armv7s,+d32,+dsp,+fp16,+fp64,+hwdiv,+hwdiv-arm,+neon,+thumb-mode,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp,+vfp4,+vfp4d16,+vfp4d16sp,+vfp4sp"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
[CodeGen] Add thumb-mode to target-features for arm/thumb triples. Summary: The thumb-mode target feature is used to force Thumb or ARM code generation on a per-function basis. Explicitly adding +thumb-mode to functions for thumbxx triples enables mixed ARM/Thumb code generation in places where compilation units with thumbxx and armxx triples are merged together (e.g. the IR linker or LTO). For armxx triples, -thumb-mode is added in a similar fashion. Reviewers: echristo, t.p.northover, kristof.beyls, rengolin Reviewed By: echristo Subscribers: rinon, aemerson, mehdi_amini, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D33448 llvm-svn: 304897
2017-06-07 19:50:45 +08:00
// RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a15 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV-ARM
// RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a17 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV-ARM
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP4-DIV-ARM: "target-features"="+armv7-a,+d32,+dsp,+fp16,+fp64,+hwdiv,+hwdiv-arm,+neon,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp,+vfp4,+vfp4d16,+vfp4d16sp,+vfp4sp,-thumb-mode"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
// RUN: %clang_cc1 -triple thumbv7s-apple-ios7.0 -target-cpu cyclone -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
[ARM] Clang tests for ARM Cortex-A32 support Patch by Sam Parker. llvm-svn: 263957
2016-03-22 01:29:51 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a32 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
Teaches clang about Cortex-A35. Adds support for the new Cortex-A35 ARMv8-A core. Differential Revision: http://reviews.llvm.org/D15142 llvm-svn: 254505
2015-12-02 20:03:42 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a35 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a72 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
This adds target support and tests for Cortex-A73 Differential Revision: http://reviews.llvm.org/D20864 llvm-svn: 271507
2016-06-02 18:48:37 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a73 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
Add support for Samsung Exynos M3 (NFC) llvm-svn: 289614
2016-12-14 07:31:57 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m3 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-BASIC-V8: "target-features"="+armv8-a,+crc,+crypto,+d32,+dsp,+fp-armv8,+fp-armv8d16,+fp-armv8d16sp,+fp-armv8sp,+fp16,+fp64,+hwdiv,+hwdiv-arm,+neon,+thumb-mode,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp,+vfp4,+vfp4d16,+vfp4d16sp,+vfp4sp"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
[test] Update support for Exynos M4 (NFC) Update test cases for Exynos M4. llvm-svn: 350954
2019-01-12 02:54:41 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m4 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V82
[clang] Add support for Exynos M5 (NFC) Add Exynos M5 test cases. llvm-svn: 356794
2019-03-23 02:44:09 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m5 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V82
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-BASIC-V82: "target-features"="+armv8.2-a,+crc,+crypto,+d32,+dotprod,+dsp,+fp-armv8,+fp-armv8d16,+fp-armv8d16sp,+fp-armv8sp,+fp16,+fp64,+fullfp16,+hwdiv,+hwdiv-arm,+neon,+ras,+thumb-mode,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp,+vfp4,+vfp4d16,+vfp4d16sp,+vfp4sp"
[test] Update support for Exynos M4 (NFC) Update test cases for Exynos M4. llvm-svn: 350954
2019-01-12 02:54:41 +08:00
[CodeGen] Add thumb-mode to target-features for arm/thumb triples. Summary: The thumb-mode target feature is used to force Thumb or ARM code generation on a per-function basis. Explicitly adding +thumb-mode to functions for thumbxx triples enables mixed ARM/Thumb code generation in places where compilation units with thumbxx and armxx triples are merged together (e.g. the IR linker or LTO). For armxx triples, -thumb-mode is added in a similar fashion. Reviewers: echristo, t.p.northover, kristof.beyls, rengolin Reviewed By: echristo Subscribers: rinon, aemerson, mehdi_amini, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D33448 llvm-svn: 304897
2017-06-07 19:50:45 +08:00
// RUN: %clang_cc1 -triple armv8-linux-gnueabi -target-cpu cortex-a53 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8-ARM
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-BASIC-V8-ARM: "target-features"="+armv8-a,+crc,+crypto,+d32,+dsp,+fp-armv8,+fp-armv8d16,+fp-armv8d16sp,+fp-armv8sp,+fp16,+fp64,+hwdiv,+hwdiv-arm,+neon,+vfp2,+vfp2sp,+vfp3,+vfp3d16,+vfp3d16sp,+vfp3sp,+vfp4,+vfp4d16,+vfp4d16sp,+vfp4sp,-thumb-mode"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
[ARM] "cortex-r5f" and "cortex-m4f" are unknown names for clang. The tests in test/CodeGen/arm-target-features.c are currently passing but warning messages are suppressed. These tests are now synchronized with the corresponding changes in Target Parser. This patch will fix the regressions in clang caused by r247136 Differential Revision: http://reviews.llvm.org/D12722 llvm-svn: 247138
2015-09-09 19:29:06 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r5 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-D16-DIV
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP3-D16-DIV: "target-features"="+armv7-r,+dsp,+fp64,+hwdiv,+hwdiv-arm,+thumb-mode,+vfp2,+vfp2sp,+vfp3d16,+vfp3d16sp"
Refactoring of how ARMTargetInfo handles default target features. Differential Revision: http://reviews.llvm.org/D11299 llvm-svn: 246946
2015-09-07 00:15:45 +08:00
// RUN: %clang_cc1 -triple armv7-linux-gnueabi -target-cpu cortex-r4f -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-D16-THUMB-DIV
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP3-D16-THUMB-DIV: "target-features"="+armv7-r,+dsp,+fp64,+hwdiv,+vfp2,+vfp2sp,+vfp3d16,+vfp3d16sp,-thumb-mode"
Refactoring of how ARMTargetInfo handles default target features. Differential Revision: http://reviews.llvm.org/D11299 llvm-svn: 246946
2015-09-07 00:15:45 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r7 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-D16-FP16-DIV
Add more ARM Cortex-R8 regression tests to Clang. Summary: This patch adds Clang tests for Cortex-R8 related to FP capabilities and hardware integer divide. Reviewers: rengolin, bsmith Subscribers: aemerson, cfe-commits, rengolin Differential Revision: http://reviews.llvm.org/D18193 llvm-svn: 263632
2016-03-16 18:21:04 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r8 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-D16-FP16-DIV
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP3-D16-FP16-DIV: "target-features"="+armv7-r,+dsp,+fp16,+fp64,+hwdiv,+hwdiv-arm,+thumb-mode,+vfp2,+vfp2sp,+vfp3d16,+vfp3d16sp"
Refactoring of how ARMTargetInfo handles default target features. Differential Revision: http://reviews.llvm.org/D11299 llvm-svn: 246946
2015-09-07 00:15:45 +08:00
[ARM] "cortex-r5f" and "cortex-m4f" are unknown names for clang. The tests in test/CodeGen/arm-target-features.c are currently passing but warning messages are suppressed. These tests are now synchronized with the corresponding changes in Target Parser. This patch will fix the regressions in clang caused by r247136 Differential Revision: http://reviews.llvm.org/D12722 llvm-svn: 247138
2015-09-09 19:29:06 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-m4 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-D16-SP-THUMB-DIV
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP4-D16-SP-THUMB-DIV: "target-features"="+armv7e-m,+dsp,+fp16,+hwdiv,+thumb-mode,+vfp2sp,+vfp3d16sp,+vfp4d16sp"
Refactoring of how ARMTargetInfo handles default target features. Differential Revision: http://reviews.llvm.org/D11299 llvm-svn: 246946
2015-09-07 00:15:45 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-m7 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP5-D16-THUMB-DIV
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-VFP5-D16-THUMB-DIV: "target-features"="+armv7e-m,+dsp,+fp-armv8d16,+fp-armv8d16sp,+fp16,+fp64,+hwdiv,+thumb-mode,+vfp2,+vfp2sp,+vfp3d16,+vfp3d16sp,+vfp4d16,+vfp4d16sp"
Refactoring of how ARMTargetInfo handles default target features. Differential Revision: http://reviews.llvm.org/D11299 llvm-svn: 246946
2015-09-07 00:15:45 +08:00
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
// RUN: %clang_cc1 -triple armv7-linux-gnueabi -target-cpu cortex-r4 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-THUMB-DIV
[ARM] Compute a target feature which corresponds to the ARM version. Currently, the interaction between the triple, the CPU, and the supported features is a mess: the driver edits the triple to indicate the supported architecture version, and the LLVM backend uses this to figure out what instructions are legal. This makes it difficult to understand what's happening, and makes it impossible to LTO together two modules with different computed architectures. Instead of relying on triple rewriting to get the correct target features, we should add the right target features explicitly. Differential Revision: https://reviews.llvm.org/D45240 llvm-svn: 330169
2018-04-17 07:52:58 +08:00
// CHECK-THUMB-DIV: "target-features"="+armv7-r,+dsp,+hwdiv,-thumb-mode"
Recommit r248154: [ARM] Handle DSP feature as an ArchExtKind Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in a hand-rolled tricky condition block in lib/Basic/Targets.cpp, with a FIXME: attached. http://reviews.llvm.org/D12937 moved the handling of the DSP feature over to ARMTargetParser.def in LLVM, to be in line with other architecture extensions. This is the corresponding patch to clang, to clear the FIXME: and update the tests. Differential Revision: http://reviews.llvm.org/D12938 llvm-svn: 248521
2015-09-25 01:34:05 +08:00
// RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-m3 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-THUMB-DIV-M3
[ARM] Compute a target feature which corresponds to the ARM version. Currently, the interaction between the triple, the CPU, and the supported features is a mess: the driver edits the triple to indicate the supported architecture version, and the LLVM backend uses this to figure out what instructions are legal. This makes it difficult to understand what's happening, and makes it impossible to LTO together two modules with different computed architectures. Instead of relying on triple rewriting to get the correct target features, we should add the right target features explicitly. Differential Revision: https://reviews.llvm.org/D45240 llvm-svn: 330169
2018-04-17 07:52:58 +08:00
// CHECK-THUMB-DIV-M3: "target-features"="+armv7-m,+hwdiv,+thumb-mode"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
[ARM] Compute a target feature which corresponds to the ARM version. Currently, the interaction between the triple, the CPU, and the supported features is a mess: the driver edits the triple to indicate the supported architecture version, and the LLVM backend uses this to figure out what instructions are legal. This makes it difficult to understand what's happening, and makes it impossible to LTO together two modules with different computed architectures. Instead of relying on triple rewriting to get the correct target features, we should add the right target features explicitly. Differential Revision: https://reviews.llvm.org/D45240 llvm-svn: 330169
2018-04-17 07:52:58 +08:00
// (The following test with no arch specified shouldn't happen; the driver
// rewrites triples. Just make sure it does something sane.)
// RUN: %clang_cc1 -triple arm-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARM-NOARCH-LINUX
// CHECK-ARM-NOARCH-LINUX: "target-features"="-thumb-mode"
// RUN: %clang_cc1 -triple armv4-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV4-LINUX
// CHECK-ARMV4-LINUX: "target-features"="+armv4,-thumb-mode"
// RUN: %clang_cc1 -triple armv4t-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV4T-LINUX
// CHECK-ARMV4T-LINUX: "target-features"="+armv4t,-thumb-mode"
// RUN: %clang_cc1 -triple armv5t-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV5T-LINUX
// CHECK-ARMV5T-LINUX: "target-features"="+armv5t,-thumb-mode"
// RUN: %clang_cc1 -triple armv6-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV6-LINUX
// CHECK-ARMV6-LINUX: "target-features"="+armv6,-thumb-mode"
// RUN: %clang_cc1 -triple armv6k-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV6K-LINUX
// CHECK-ARMV6K-LINUX: "target-features"="+armv6k,-thumb-mode"
// RUN: %clang_cc1 -triple arm-linux-gnueabi -target-cpu mpcorenovfp -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV6K-MPCORE-LINUX
// CHECK-ARMV6K-MPCORE-LINUX: "target-features"="+armv6k,+dsp,-thumb-mode"
// RUN: %clang_cc1 -triple armv6t2-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV6T2-LINUX
// CHECK-ARMV6T2-LINUX: "target-features"="+armv6t2,-thumb-mode"
// RUN: %clang_cc1 -triple thumbv6m-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV6M-LINUX
// RUN: %clang_cc1 -triple thumb-linux-gnueabi -target-cpu cortex-m0 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV6M-LINUX
// CHECK-ARMV6M-LINUX: "target-features"="+armv6-m,+thumb-mode"
// RUN: %clang_cc1 -triple thumbv7m-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV7M-LINUX
// CHECK-ARMV7M-LINUX: "target-features"="+armv7-m,+thumb-mode"
// RUN: %clang_cc1 -triple thumb-linux-gnueabi -target-cpu cortex-m3 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV7M-M3-LINUX
// CHECK-ARMV7M-M3-LINUX: "target-features"="+armv7-m,+hwdiv,+thumb-mode"
// RUN: %clang_cc1 -triple thumbv8m.base-linux-gnueabi -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV8M-LINUX
// CHECK-ARMV8M-LINUX: "target-features"="+armv8-m.base,+thumb-mode"
// RUN: %clang_cc1 -triple thumb-linux-gnueabi -target-cpu cortex-m23 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV8M-M23-LINUX
// CHECK-ARMV8M-M23-LINUX: "target-features"="+armv8-m.base,+hwdiv,+thumb-mode"
// RUN: %clang_cc1 -triple thumb-linux-gnueabi -target-cpu cortex-m33 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV8M-MAIN-LINUX
[ARM][MVE] MVE-I should not be disabled by -mfpu=none Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
2020-01-09 21:47:52 +08:00
// CHECK-ARMV8M-MAIN-LINUX: "target-features"="+armv8-m.main,+dsp,+fp-armv8d16sp,+fp16,+hwdiv,+thumb-mode,+vfp2sp,+vfp3d16sp,+vfp4d16sp"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
[ARM] Add Cortex-M55 Support for clang and llvm This patch upstreams support for the ARM Armv8.1m cpu Cortex-M55. In detail adding support for: - mcpu option in clang - Arm Target Features in clang - llvm Arm TargetParser definitions details of the CPU can be found here: https://developer.arm.com/ip-products/processors/cortex-m/cortex-m55 Reviewers: chill Reviewed By: chill Subscribers: dmgreen, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D74966
2020-02-14 21:33:32 +08:00
// RUN: %clang_cc1 -triple thumb-linux-gnueabi -target-cpu cortex-m55 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ARMV81M-MAIN-LINUX
// CHECK-ARMV81M-MAIN-LINUX: "target-features"="+armv8.1-m.main,+dsp,+fp-armv8d16,+fp-armv8d16sp,+fp16,+fp64,+fullfp16,+hwdiv,+lob,+mve,+mve.fp,+ras,+thumb-mode,+vfp2,+vfp2sp,+vfp3d16,+vfp3d16sp,+vfp4d16,+vfp4d16sp"
ARM: merge Cyclone into other ARMv8 CPUs and add tests for features. Cyclone actually supports all the goodies you'd expect to come with an AArch64 CPU, so it doesn't need its own clause. Also we should probably be testing these clauses. llvm-svn: 236349
2015-05-02 05:17:25 +08:00
void foo() {}