summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/arm-target-features.c
Commit message (Collapse)AuthorAgeFilesLines
* [clang][Driver][ARM] Favor -mfpu over default CPU featuresAlexandros Lamprineas2019-07-141-1/+1
| | | | | | | | | | | | | | | | When processing the command line options march, mcpu and mfpu, we store the implied target features on a vector. The change D62998 introduced a temporary vector, where the processed features get accumulated. When calling DecodeARMFeaturesFromCPU, which sets the default features for the specified CPU, we certainly don't want to override the features that have been explicitly specified on the command line. Therefore, the default features should appear first in the final vector. This problem became evident once I added the missing (unhandled) target features in ARM::getExtensionFeatures. Differential Revision: https://reviews.llvm.org/D63936 llvm-svn: 366027
* [ARM] Fix bugs introduced by the fp64/d32 rework.Simon Tatham2019-06-071-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
* [ARM] Replace fp-only-sp and d16 with fp64 and d32.Simon Tatham2019-05-281-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits. Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options. A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60691 llvm-svn: 361845
* [clang] Add support for Exynos M5 (NFC)Evandro Menezes2019-03-221-0/+1
| | | | | | Add Exynos M5 test cases. llvm-svn: 356794
* [test] Update support for Exynos M4 (NFC)Evandro Menezes2019-01-111-1/+3
| | | | | | Update test cases for Exynos M4. llvm-svn: 350954
* [PATCH 2/2] [test] Add support for Samsung Exynos M4 (NFC)Evandro Menezes2018-06-061-0/+1
| | | | | | Add test cases for Exynos M4. llvm-svn: 334116
* [ARM] Compute a target feature which corresponds to the ARM version.Eli Friedman2018-04-161-14/+59
| | | | | | | | | | | | | | | | 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
* [CodeGen] Add thumb-mode to target-features for arm/thumb triples.Florian Hahn2017-06-071-18/+16
| | | | | | | | | | | | | | | | | | | | | 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
* Add support for Samsung Exynos M3 (NFC)Evandro Menezes2016-12-131-0/+1
| | | | llvm-svn: 289614
* [AArch64] Add support for Samsung Exynos M2 (NFC).Evandro Menezes2016-08-011-0/+1
| | | | llvm-svn: 277365
* This adds target support and tests for Cortex-A73Sjoerd Meijer2016-06-021-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D20864 llvm-svn: 271507
* [ARM] Clang tests for ARM Cortex-A32 supportRenato Golin2016-03-211-0/+1
| | | | | | Patch by Sam Parker. llvm-svn: 263957
* Add more ARM Cortex-R8 regression tests to Clang.Pablo Barrio2016-03-161-0/+1
| | | | | | | | | | | | | | 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
* [AArch64] Teaches clang about Samsung Exynos-M1MinSeong Kim2016-01-051-0/+1
| | | | | | | | Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15664 llvm-svn: 256829
* Teaches clang about Cortex-A35.Christof Douma2015-12-021-0/+1
| | | | | | | | Adds support for the new Cortex-A35 ARMv8-A core. Differential Revision: http://reviews.llvm.org/D15142 llvm-svn: 254505
* [ARM] Renaming +t2dsp feature into +dsp, as discussed on llvm-devArtyom Skrobov2015-10-231-11/+11
| | | | llvm-svn: 251124
* Recommit r248154: [ARM] Handle DSP feature as an ArchExtKindArtyom Skrobov2015-09-241-12/+14
| | | | | | | | | | | | | | | | 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
* Revert "[ARM] Handle +t2dsp feature as an ArchExtKind in ARMTargetParser.def"James Molloy2015-09-211-14/+12
| | | | | | | | This was committed without the code review (http://reviews.llvm.org/D12938) being approved. This reverts commit r248154. llvm-svn: 248173
* [ARM] Handle +t2dsp feature as an ArchExtKind in ARMTargetParser.defArtyom Skrobov2015-09-211-12/+14
| | | | | | | | | | | | | | | | 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 +t2dsp 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: 248154
* [ARM] "cortex-r5f" and "cortex-m4f" are unknown names for clang.Alexandros Lamprineas2015-09-091-7/+2
| | | | | | | | | | | | 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
* Refactoring of how ARMTargetInfo handles default target features.Alexandros Lamprineas2015-09-061-2/+25
| | | | | | Differential Revision: http://reviews.llvm.org/D11299 llvm-svn: 246946
* Use a stable sort to guarantee target feature ordering in the IREric Christopher2015-07-011-3/+3
| | | | | | | in order to make testing somewhat more feasible. Has the advantage of making it easier to find target features as well. llvm-svn: 241134
* ARM: merge Cyclone into other ARMv8 CPUs and add tests for features.Tim Northover2015-05-011-0/+38
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
OpenPOWER on IntegriCloud