summaryrefslogtreecommitdiffstats
path: root/clang/test/Preprocessor/arm-target-features.c
Commit message (Collapse)AuthorAgeFilesLines
* [clang][llvm] Obsolete Exynos M1 and M2Evandro Menezes2019-10-301-8/+0
|
* [TargetParser][ARM] Account dependencies when processing target featuresAlexandros Lamprineas2019-07-141-6/+23
| | | | | | | | | | Teaches ARM::appendArchExtFeatures to account dependencies when processing target features: i.e. when you say -march=armv8.1-m.main+mve.fp+nofp it means mve.fp should get discarded too. (Split from D63936) Differential Revision: https://reviews.llvm.org/D64048 llvm-svn: 366031
* [ARM] Add ACLE feature macros for MVESjoerd Meijer2019-06-071-0/+21
| | | | | | | | | | | | | | | If MVE is present at all, then the macro __ARM_FEATURE_MVE is defined to a value which has bit 0 set for integer MVE, and bit 1 set for floating-point MVE. (Floating-point MVE implies integer MVE, so if this macro is defined at all then it will be set to 1 or 3, never 2.) Patch mostly by Simon Tatham Differential Revision: https://reviews.llvm.org/D60710 llvm-svn: 362806
* [ARM] Fix bugs introduced by the fp64/d32 rework.Simon Tatham2019-06-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][CMSE] Add commandline option and feature macroJaved Absar2019-05-211-0/+20
| | | | | | | | | | | Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces -mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3. A diagnostic is produced when the option is given on architectures without support for Security Extensions. Reviewed By: dmgreen, snidertm Differential Revision: https://reviews.llvm.org/D59879 llvm-svn: 361261
* [clang] Add support for Exynos M5 (NFC)Evandro Menezes2019-03-221-0/+4
| | | | | | Add Exynos M5 test cases. llvm-svn: 356794
* [ARM/AArch64][v8.5A] Add Armv8.5-A targetOliver Stannard2018-09-261-0/+15
| | | | | | | | | | | This patch allows targetting Armv8.5-A from Clang. Most of the implementation is in TargetParser, so this is mostly just adding tests. Patch by Pablo Barrio! Differential revision: https://reviews.llvm.org/D52491 llvm-svn: 343111
* [ARM][AArch64] Add feature +fp16fmlSjoerd Meijer2018-09-241-3/+43
| | | | | | | | | | | | | | | | | | | | | Armv8.4-A adds a few FP16 instructions that can optionally be implemented in CPUs of Armv8.2-A and above. This patch adds a feature to clang to permit selection of these instructions. This interacts with the +fp16 option as follows: Prior to Armv8.4-A: *) +fp16fml implies +fp16 *) +nofp16 implies +nofp16fml From Armv8.4-A: *) The above conditions apply, additionally: +fp16 implies +fp16fml Patch by Bernard Ogden. Differential Revision: https://reviews.llvm.org/D50229 llvm-svn: 342862
* [PATCH 2/2] [test] Add support for Samsung Exynos M4 (NFC)Evandro Menezes2018-06-061-0/+18
| | | | | | Add test cases for Exynos M4. llvm-svn: 334116
* [ARM] Add __ARM_FEATURE_DOTPROD pre-defined macroOliver Stannard2018-04-271-0/+5
| | | | | | | | | | | | | | This adds a pre-defined macro to test if the compiler has support for the v8.2-A dot rpoduct intrinsics in AArch32 mode. The AAcrh64 equivalent has already been added by rL330229. The ACLE spec which describes this macro hasn't been published yet, but this is based on the final internal draft, and GCC has already implemented this. Differential revision: https://reviews.llvm.org/D46108 llvm-svn: 331038
* [ARM] ACLE FP16 feature test macrosSjoerd Meijer2018-03-131-0/+12
| | | | | | | | | This is a partial recommit of r327189 that was reverted due to test issues. I.e., this recommits minimal functional change, the FP16 feature test macros, and adds tests that were missing in the original commit. llvm-svn: 327455
* [ARM] disable FPU features when using soft floating point.Keith Walker2018-02-191-47/+264
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid int to string conversion in Twine or raw_ostream contexts.Benjamin Kramer2017-12-281-34/+34
| | | | | | Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
* Revert [ARM] disable FPU features when using soft floating point.Keith Walker2017-11-301-264/+45
| | | | | | | This reverts r319420 It is failing the test Driver/arm-mfpu.c so reverting while I investigate the failure. llvm-svn: 319425
* [ARM] disable FPU features when using soft floating point.Keith Walker2017-11-301-45/+264
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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/D40256 llvm-svn: 319420
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a re-apply of r319294. adds -fseh-exceptions and -fdwarf-exceptions flags clang will check if the user has specified an exception model flag, in the absense of specifying the exception model clang will then check the driver default and append the model flag for that target to cc1 -fno-exceptions has a higher priority then specifying the model move __SEH__ macro definitions out of Targets into InitPreprocessor behind the -fseh-exceptions flag move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check remove unused USESEHExceptions from the MinGW Driver fold USESjLjExceptions into a new GetExceptionModel function that gives the toolchain classes more flexibility with eh models Reviewers: rnk, mstorsjo Differential Revision: https://reviews.llvm.org/D39673 llvm-svn: 319297
* Revert "Toolchain: Normalize dwarf, sjlj and seh eh"Martell Malone2017-11-291-2/+0
| | | | | | | | This reverts rL319294. The windows sanitizer does not like seh on x86. Will re apply with None type for x86 llvm-svn: 319295
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | adds -fseh-exceptions and -fdwarf-exceptions flags clang will check if the user has specified an exception model flag, in the absense of specifying the exception model clang will then check the driver default and append the model flag for that target to cc1 clang cc1 assumes dwarf is the default if none is passed and -fno-exceptions has a higher priority then specifying the model move __SEH__ macro definitions out of Targets into InitPreprocessor behind the -fseh-exceptions flag move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check remove unused USESEHExceptions from the MinGW Driver fold USESjLjExceptions into a new GetExceptionModel function that gives the toolchain classes more flexibility with eh models Reviewers: rnk, mstorsjo Differential Revision: https://reviews.llvm.org/D39673 llvm-svn: 319294
* ARMV8-A archkind and target defines helper functionsSjoerd Meijer2017-06-301-0/+1
| | | | | | | | | | | | This introduces helper functions that set target defines for different ARMV8-A architecture kinds. It fixes an issue that the v8.1 define ARM_FEATURE_QRDMX was not set for v8.2. These helper functions make things more “scalable” if we want to add ARMv8.3 at some point, and a cleanup has been done to hold the architecture kind in one variable (instead of one for each). Differential Revision: https://reviews.llvm.org/D34686 llvm-svn: 306805
* [ARM] Add regression tests for Cortex-M23 and Cortex-M33Sanne Wouda2017-02-201-0/+25
| | | | | | | | | | | | Reviewers: rengolin, t.p.northover Reviewed By: t.p.northover Subscribers: aemerson, llvm-commits Differential Revision: https://reviews.llvm.org/D30100 llvm-svn: 295647
* Add support for armv7ve flag in clang (PR31358).George Burgess IV2017-02-091-0/+7
| | | | | | | | | | | This is a followup change to add v7ve support to clang for gcc compatibility. Please see r294661. Patch by Manoj Gupta. Differential Revision: https://reviews.llvm.org/D29773 llvm-svn: 294662
* ARM: define a macro for the FPv5 FPU in ARM mode.Tim Northover2016-12-211-0/+1
| | | | | | | FPv5 is in Cortex-M7 and the 64-bit CPUs when running in 32-bit mode. The name is from the Cortex-M7 TRM. llvm-svn: 290268
* [ARM]: Add Cortex-R52 targetJaved Absar2016-10-071-0/+9
| | | | | | | This patch adds Cortex-R52, the new ARM real-time processor. Cortex-R52 implements the ARMv8-R architecture. llvm-svn: 283543
* Add a few missing Clang regression tests for Cortex-A53, Cortex-A57, Cortex-A72Sjoerd Meijer2016-06-031-0/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D20908 llvm-svn: 271636
* This adds target support and tests for Cortex-A73Sjoerd Meijer2016-06-021-0/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D20864 llvm-svn: 271507
* [Clang][Darwin] Define __ARM_DWARF_EH__ for WatchABIChris Bieneman2016-04-291-0/+1
| | | | | | | | | | | | Summary: The Darwin armv7k ABI uses Dwarf EH, so we need to set the OS define correctly. Without this the gcc_personality fails to build. Reviewers: t.p.northover Subscribers: aemerson, cfe-commits, rengolin Differential Revision: http://reviews.llvm.org/D19693 llvm-svn: 268078
* Add accidentally dropped test to r267880.Tim Northover2016-04-281-0/+10
| | | | | | Forgot "git add". llvm-svn: 267881
* Clean up a couple more preprocessor tests to use match-full-lines.James Y Knight2016-04-011-179/+179
| | | | llvm-svn: 265187
* Combine identical check-prefixes in Clang ↵Artyom Skrobov2016-03-231-149/+75
| | | | | | | | | | | | test/Preprocessor/arm-target-features.c Reviewers: rengolin, t.p.northover Subscribers: aemerson, cfe-commits, rengolin Differential Revision: http://reviews.llvm.org/D18391 llvm-svn: 264155
* [ARM] Clang tests for ARM Cortex-A32 supportRenato Golin2016-03-211-10/+12
| | | | | | Patch by Sam Parker. llvm-svn: 263957
* Add more ARM Cortex-R8 regression tests to Clang.Pablo Barrio2016-03-161-10/+12
| | | | | | | | | | | | | | 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
* Test commit - Remove some trailing whitespacePablo Barrio2016-03-151-1/+1
| | | | llvm-svn: 263574
* [ARM] Add Clang targeting for ARMv8-M Baseline/MainlineBradley Smith2016-03-031-0/+36
| | | | llvm-svn: 262619
* [ARM] Add command-line options for ARMv8.2-AOliver Stannard2016-02-111-0/+6
| | | | | | | | | | | | | | | | | This allows ARMv8.2-A to be targeted either by using "armv8.2a" in the triple, or by using -march=armv8.2-a (or the alias -march=armv8.2a). The FP16 extension can be enabled with the "+fp16" suffix to the -march or -mcpu option. This is consistent with the AArch64 option, rather than the usual ARM option of -mfpu. We have agreed with the team which will be upstreaming this to GCC that we want to use this new option format for new architecture extensions for both ARM and AArch64. Most of the work for this was done by the TargetParser patch in llvm. Differential Revision: http://reviews.llvm.org/D15040 llvm-svn: 260533
* ARM v8.1a adds Advanced SIMD instructions for Rounding Double MultiplyAlexandros Lamprineas2015-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Add/Subtract. The following instructions are added to AArch32 instruction set: - VQRDMLAH: Vector Saturating Rounding Doubling Multiply Accumulate Returning High Half - VQRDMLSH: Vector Saturating Rounding Doubling Multiply Subtract Returning High Half The following instructions are added to AArch64 instruction set: - SQRDMLAH: Signed Saturating Rounding Doubling Multiply Accumulate Returning High Half - SQRDMLSH: Signed Saturating Rounding Doubling Multiply Subtract Returning High Half This patch adds intrinsic and ACLE macro support for these instructions, as well as corresponding tests. Differential Revision: http://reviews.llvm.org/D14982 llvm-svn: 254250
* Support watchOS and tvOS driver optionsTim Northover2015-10-301-3/+2
| | | | | | | | This patch should add support for almost all command-line options and driver tinkering necessary to produce a correct "clang -cc1" invocation for watchOS and tvOS. llvm-svn: 251706
* Fix __ARM_FP value for sp-only FPUs with Half-precisionRichard Barton2015-10-211-10/+61
| | | | | | | | | The logic for parsing FP capabilities to set __ARM_FP was mistakenly removing the Half-Precision capability when handling fp-only-sp resulting in a value of 0x4. Section 6.5.1 of ACLE states that for such FP architectures the value should be 0x6 llvm-svn: 250888
* Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] ↵Alexandros Lamprineas2015-10-021-0/+9
| | | | | | | | targets. Differential Revision: http://reviews.llvm.org/D12633 llvm-svn: 249140
* [ARM] Allow passing/returning of __fp16 argumentsOliver Stannard2015-09-031-0/+2
| | | | | | | | | | | | | | | | | | | | | The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be used as a functon argument or return type (ACLE 1.1 did not). The current public release of the AAPCS (2.09) states that __fp16 values should be converted to single-precision before being passed or returned, but AAPCS 2.10 (to be released shortly) changes this, so that they are passed in the least-significant 16 bits of either a GPR (for base AAPCS) or a single-precision register (for AAPCS-VFP). This does not change how arguments are passed if they get passed on the stack. This patch brings clang up to compliance with the latest versions of both of these specs. We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support the alternative format). llvm-svn: 246764
* Revert 246755 as it breaks buildbotsOliver Stannard2015-09-031-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | Original commit message: [ARM] Allow passing/returning of __fp16 arguments The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be used as a functon argument or return type (ACLE 1.1 did not). The current public release of the AAPCS (2.09) states that __fp16 values should be converted to single-precision before being passed or returned, but AAPCS 2.10 (to be released shortly) changes this, so that they are passed in the least-significant 16 bits of either a GPR (for base AAPCS) or a single-precision register (for AAPCS-VFP). This does not change how arguments are passed if they get passed on the stack. This patch brings clang up to compliance with the latest versions of both of these specs. We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support the alternative format). llvm-svn: 246760
* [ARM] Allow passing/returning of __fp16 argumentsOliver Stannard2015-09-031-0/+2
| | | | | | | | | | | | | | | | | | | | | The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be used as a functon argument or return type (ACLE 1.1 did not). The current public release of the AAPCS (2.09) states that __fp16 values should be converted to single-precision before being passed or returned, but AAPCS 2.10 (to be released shortly) changes this, so that they are passed in the least-significant 16 bits of either a GPR (for base AAPCS) or a single-precision register (for AAPCS-VFP). This does not change how arguments are passed if they get passed on the stack. This patch brings clang up to compliance with the latest versions of both of these specs. We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support the alternative format). llvm-svn: 246755
* ARM: actually define __ARM_ARCH_7S__ for the armv7s sliceTim Northover2015-07-211-1/+8
| | | | | | | We ended up with the wrong predefine after the recent TargetParser shuffle, and I accidentally solidified it with a test. This should fix it. llvm-svn: 242841
* [ARM] Use TargetParser to determine FPU subtarget featuresJohn Brawn2015-06-051-2/+2
| | | | | | | | | | | | | | | 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
* ARM: fix ACLE predefine for iOS's "-arch armv7s".Tim Northover2015-05-291-0/+1
| | | | | | We were getting "#define __ARM_ARCH_7 -S__ 1" which is really not a good idea. llvm-svn: 238614
* [ARM] Add v8.1a architectureVladimir Sukharev2015-05-141-0/+5
| | | | | | | | | | | | | | Add support for ARMv8.1a architecture. Briefly it is described on http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development Reviewers: jmolloy, rengolin Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D8799 llvm-svn: 237349
* [ARM] add support for Cortex-R4/R4FJaved Absar2015-04-091-0/+18
| | | | | | | | Adds ARM Cortex-R4 and R4F support and tests in Clang. Though Cortex-R4 support was present, the support for hwdiv in thumb-mode was not defined or tested properly. This has also been added. llvm-svn: 234488
* [ARM] Add missing M/R class CPUsBradley Smith2015-02-181-0/+13
| | | | | | | | | | | | Add some of the missing M and R class Cortex CPUs, namely: Cortex-M0+ (called Cortex-M0plus for GCC compatibility) Cortex-M1 SC000 SC300 Cortex-R5 llvm-svn: 229661
* [ARM] Define __ARM_FEATURE_DSP macro for CPUs that have DSP instructionsSergey Dmitrouk2014-11-251-1/+32
| | | | | | | | | | | | | | | | | Summary: This resolves [[ http://llvm.org/bugs/show_bug.cgi?id=17391 | PR17391 ]]. GCC's sources were used as a guide (couldn't find much information in ARM documentation). Reviewers: doug.gregor, asl Reviewed By: asl Subscribers: asl, aemerson, cfe-commits Differential Revision: http://reviews.llvm.org/D6339 llvm-svn: 222741
* Adds support for the Cortex-A17 processor to ClangRenato Golin2014-10-131-0/+19
| | | | | | Patch by Matthew Wahab. llvm-svn: 219607
* [ARM] Add support for Cortex-M7, FPv5-SP and FPv5-DPOliver Stannard2014-10-011-0/+4
| | | | | | | | | 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
OpenPOWER on IntegriCloud