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

112 lines
8.1 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] 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-VFP3: "target-features"="+armv7-a,+dsp,+neon,+thumb-mode,+vfp3"
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] 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-VFP4: "target-features"="+armv7-a,+dsp,+neon,+thumb-mode,+vfp4"
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] 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-VFP4-DIV: "target-features"="+armv7-a,+dsp,+hwdiv,+hwdiv-arm,+neon,+thumb-mode,+vfp4"
// CHECK-VFP4-DIV-2: "target-features"="+armv7s,+dsp,+hwdiv,+hwdiv-arm,+neon,+thumb-mode,+vfp4"
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] 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-VFP4-DIV-ARM: "target-features"="+armv7-a,+dsp,+hwdiv,+hwdiv-arm,+neon,+vfp4,-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
[AArch64] Teaches clang about Samsung Exynos-M1 Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15664 llvm-svn: 256829
2016-01-05 20:53:24 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m1 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
[AArch64] Add support for Samsung Exynos M2 (NFC). llvm-svn: 277365
2016-08-02 02:39:55 +08:00
// RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu exynos-m2 -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] 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-BASIC-V8: "target-features"="+armv8-a,+crc,+crypto,+dsp,+fp-armv8,+hwdiv,+hwdiv-arm,+neon,+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
[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
// CHECK-BASIC-V82: "target-features"="+armv8.2-a,+crc,+crypto,+dotprod,+dsp,+fp-armv8,+hwdiv,+hwdiv-arm,+neon,+ras,+thumb-mode"
[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] 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-BASIC-V8-ARM: "target-features"="+armv8-a,+crc,+crypto,+dsp,+fp-armv8,+hwdiv,+hwdiv-arm,+neon,-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] 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-VFP3-D16-DIV: "target-features"="+armv7-r,+d16,+dsp,+hwdiv,+hwdiv-arm,+thumb-mode,+vfp3"
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] 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-VFP3-D16-THUMB-DIV: "target-features"="+armv7-r,+d16,+dsp,+hwdiv,+vfp3,-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] 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-VFP3-D16-FP16-DIV: "target-features"="+armv7-r,+d16,+dsp,+fp16,+hwdiv,+hwdiv-arm,+thumb-mode,+vfp3"
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] 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-VFP4-D16-SP-THUMB-DIV: "target-features"="+armv7e-m,+d16,+dsp,+fp-only-sp,+hwdiv,+thumb-mode,+vfp4"
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] 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-VFP5-D16-THUMB-DIV: "target-features"="+armv7e-m,+d16,+dsp,+fp-armv8,+hwdiv,+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
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
// CHECK-ARMV8M-MAIN-LINUX: "target-features"="+armv8-m.main,+d16,+dsp,+fp-armv8,+fp-only-sp,+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
void foo() {}