summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/Arch/ARM.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Make helper functions static or move them into anonymous namespaces. NFC.Benjamin Kramer2020-01-141-3/+3
|
* [ARM][MVE] MVE-I should not be disabled by -mfpu=noneMomchil Velikov2020-01-091-20/+23
| | | | | | | | | | | | | | | 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
* Revert "[ARM] Allocatable Global Register Variables for ARM"Carey Williams2019-11-291-33/+5
| | | | This reverts commit 2d739f98d8a53e38bf9faa88cdb6b0c2a363fb77.
* [ARM] Allocatable Global Register Variables for ARMAnna Welker2019-11-181-5/+33
| | | | | | | | | | | | Provides support for using r6-r11 as globally scoped register variables. This requires a -ffixed-rN flag in order to reserve rN against general allocation. If for a given GRV declaration the corresponding flag is not found, or the the register in question is the target's FP, we fail with a diagnostic. Differential Revision: https://reviews.llvm.org/D68862
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-191-0/+1
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* [Driver,ARM] Make -mfloat-abi=soft turn off MVE.Simon Tatham2019-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since `-mfloat-abi=soft` is taken to mean turning off all uses of the FP registers, it should turn off the MVE vector instructions as well as NEON and scalar FP. But it wasn't doing so. So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft` would cause the underlying LLVM to //not// support MVE (because it knows the real target feature relationships and turned off MVE when the `fpregs` feature was removed), but the clang layer still thought it //was// supported, and would misleadingly define the feature macro `__ARM_FEATURE_MVE`. The ARM driver code already has a long list of feature names to turn off when `-mfloat-abi=soft` is selected. The fix is to add the missing entries `mve` and `mve.fp` to that list. Reviewers: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69025 llvm-svn: 375001
* [ARM] Preserve fpu behaviour for '-crypto'Diogo N. Sampaio2019-10-141-18/+27
| | | | | | | | | | | | | | | | | | | | | Summary: This patch restores the behaviour that -fpu overwrites the architecture obtained from -march or -mcpu flags, not enforcing to disable 'crypto' if march=armv7 and mfpu=neon-fp-armv8. However, it does warn that 'crypto' is ignored when passing mfpu=crypto-neon-fp-armv8. Reviewers: peter.smith, labrinea Reviewed By: peter.smith Subscribers: nickdesaulniers, kristof.beyls, dmgreen, cfe-commits, krisb Tags: #clang Differential Revision: https://reviews.llvm.org/D67608 llvm-svn: 374785
* [ARM] Update clang for removal of vfp2d16 and vfp2d16spEli Friedman2019-09-171-1/+1
| | | | | | | | Matching fix for https://reviews.llvm.org/D67375 (r372186). Differential Revision: https://reviews.llvm.org/D67467 llvm-svn: 372187
* [ARM] Take into account -mcpu and -mfpu options while handling 'crypto' featureDiogo N. Sampaio2019-09-111-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Submittin in behalf of krisb (Kristina Bessonova) <ch.bessonova@gmail.com> Summary: '+crypto' means '+aes' and '+sha2' for arch >= ARMv8 when they were not disabled explicitly. But this is correctly handled only in case of '-march' option, though the feature may also be specified through the '-mcpu' or '-mfpu' options. In the following example: $ clang -mcpu=cortex-a57 -mfpu=crypto-neon-fp-armv8 'aes' and 'sha2' are disabled that is quite unexpected: $ clang -cc1 -triple armv8--- -target-cpu cortex-a57 <...> -target-feature -sha2 -target-feature -aes -target-feature +crypto This exposed by https://reviews.llvm.org/D63936 that makes the 'aes' and 'sha2' features disabled by default. So, while handling the 'crypto' feature we need to take into account: - a CPU name, as it provides the information about architecture (if no '-march' option specified), - features, specified by the '-mcpu' and '-mfpu' options. Reviewers: SjoerdMeijer, ostannard, labrinea, dnsampaio Reviewed By: dnsampaio Subscribers: ikudrin, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66018 Author: krisb llvm-svn: 371597
* [clang][Driver][ARM] Favor -mfpu over default CPU featuresAlexandros Lamprineas2019-07-141-1/+5
| | | | | | | | | | | | | | | | 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
* [clang][Driver][ARM] NFC: Remove unused function parameterAlexandros Lamprineas2019-07-021-7/+5
| | | | | | | | | Removes a vector reference that was added by D62998, since the preexisting function parameter is sufficient. Differential Revision: https://reviews.llvm.org/D64044 llvm-svn: 364895
* [ARM] Fix bugs introduced by the fp64/d32 rework.Simon Tatham2019-06-071-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Allow "-march=foo+fp" to vary with fooSjoerd Meijer2019-06-051-29/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now, when clang processes an argument of the form "-march=foo+x+y+z", then instead of calling getArchExtFeature() for each of the extension names "x", "y", "z" and appending the returned string to its list of low-level subtarget features, it will call appendArchExtFeatures() which does the appending itself. The difference is that appendArchExtFeatures can add _more_ than one low-level feature name to the output feature list if it has to, and also, it gets told some information about what base architecture and CPU the extension is going to go with, which means that "+fp" can now mean something different for different CPUs. Namely, "+fp" now selects whatever the _default_ FPU is for the selected CPU and/or architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in ARMTargetParser.def. On the clang side, I adjust DecodeARMFeatures to call the new appendArchExtFeatures function in place of getArchExtFeature. This means DecodeARMFeatures needs to be passed a CPU name and an ArchKind, which meant changing its call sites to make those available, and also sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind enum value out of it instead of a string. Also, I add support here for the extension name "+fp.dp", which will automatically look through the FPU list for something that looks just like the default FPU except for also supporting double precision. Differential Revision: https://reviews.llvm.org/D60697 llvm-svn: 362601
* [ARM] Fix recent breakage of -mfpu=none.Simon Tatham2019-06-031-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent change D60691 introduced a bug in clang when handling option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those options together should select Cortex-M4 but disable all use of hardware FP, but in fact, now hardware FP instructions can still be generated in that mode. The reason is because the handling of FPUVersion::NONE disables all the same feature names it used to, of which the base one is `vfp2`. But now there are further features below that, like `vfp2d16fp` and (following D60694) `fpregs`, which also need to be turned off to disable hardware FP completely. Added a tiny test which double-checks that compiling a simple FP function doesn't access the FP registers. Reviewers: SjoerdMeijer, dmgreen Reviewed By: dmgreen Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62729 llvm-svn: 362380
* [ARM][CMSE] Add commandline option and feature macroJaved Absar2019-05-211-0/+4
| | | | | | | | | | | 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
* [ARM] Fix the extensions implied by a cpu nameDiogo N. Sampaio2019-05-091-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When using `clang -mcpu=CPUNAME+FEATURELIST`, the implied features defined by CPUNAME are not obtained, as the entire string is passed. This fixes that by spiting the cpuname string in the first `+`, if any. For example, when using ```clang -### --target=arm-arm-none-eabi -march=armv7-a -mcpu=cortex-a8+nocrc``` the intrinsic ```"target-feature" "+dsp"``` implied by `cortex-a8` is missing. Reviewers: keith.walker.arm, DavidSpickett, carwil Reviewed By: DavidSpickett Subscribers: javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61668 llvm-svn: 360324
* [Driver] Fix float ABI default for Android ARMv8.Dan Albert2019-02-211-1/+1
| | | | | | | | | | | | | | | | Summary: Android doesn't regress back to soft float after ARMv7 :) Reviewers: srhines, pirama Reviewed By: srhines, pirama Subscribers: javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58477 llvm-svn: 354622
* [Driver] Default all Android ARM targets to NEON.Dan Albert2019-02-151-3/+1
| | | | | | | | | | | | | | | | | | | | Summary: There are an insignificant number of ARM Android devices that don't support NEON. Default to using NEON since that will improve performance on the majority of devices. Users that need to target non-NEON devices can still explicitly disable NEON. Reviewers: srhines, pirama, kristof.beyls Reviewed By: pirama Subscribers: efriedma, javed.absar, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58153 llvm-svn: 354166
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [ARM][AArch64] Pass through endian flags to assembler and linker.Peter Smith2018-10-161-1/+1
| | | | | | | | | | | | | | | | | The big-endian arm32 Linux builds are currently failing when the -mbig-endian flag is used but the binutils default on the system is little endian. This also holds when -mlittle-endian is used and the binutils default is big endian. The patch always passes through -EL or -BE to the assembler and linker, taking into account the target and the -mbig-endian and -mlittle-endian flag. Fixes pr38770 Differential Revision: https://reviews.llvm.org/D52784 llvm-svn: 344597
* [Driver] Add defaults for Android ARM FPUs.Dan Albert2018-10-121-0/+7
| | | | | | | | | | | | | | | | | Summary: Android mandates that devices have at least vfpv3-d16 until Marshmallow and NEON after that. Still honor the user's decision, but raise the defaults for Android targets. Reviewers: srhines, pirama, javed.absar, kristof.beyls, peter.smith Reviewed By: peter.smith Subscribers: peter.smith, rengolin, kristof.beyls, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D53121 llvm-svn: 344367
* [AArch64][ARM] Context sensitive meaning of cryptoSjoerd Meijer2018-10-041-0/+20
| | | | | | | | | | | | | | For AArch64, crypto means: - sm4 + sha3 + sha2 + aes for Armv8.4-A and up, and - sha2 + aes for Armv8.3-A and earlier. For AArch32: Crypto means sha2 + aes, because the Armv8.2-A crypto instructions were added to AArch64 only. Differential Revision: https://reviews.llvm.org/D50179 llvm-svn: 343758
* [ARM][AArch64] Add feature +fp16fmlSjoerd Meijer2018-09-241-1/+28
| | | | | | | | | | | | | | | | | | | | | 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
* OpenBSD/arm has switched to float ABI SoftFP.Brad Smith2018-07-221-1/+1
| | | | llvm-svn: 337660
* Change \t to spacesFangrui Song2018-07-201-1/+1
| | | | llvm-svn: 337530
* Fix typos in clangAlexander Kornienko2018-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* [ARM] disable FPU features when using soft floating point.Keith Walker2018-02-191-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert [ARM] disable FPU features when using soft floating point.Keith Walker2017-11-301-15/+5
| | | | | | | 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-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ARM] Option for reading thread pointer from coprocessor registerStrahinja Petrovic2017-09-121-0/+24
| | | | | | | | | This patch enables option for reading thread pointer directly from coprocessor register (-mtp=soft/cp15). Differential Revision: https://reviews.llvm.org/D34878 llvm-svn: 313018
* [ARM][AArch64] Cortex-A75 and Cortex-A55 testsSam Parker2017-08-211-0/+11
| | | | | | | | | | | | | | | | | | Add frontend tests for Cortex-A75 and Cortex-A55, Arm's latest big.LITTLE A-class cores. They implement the ARMv8.2-A architecture, including the cryptography and RAS extensions, plus the optional dot product extension. They also implement the RCpc AArch64 extension from ARMv8.3-A. Cortex-A75: https://developer.arm.com/products/processors/cortex-a/cortex-a75 Cortex-A55: https://developer.arm.com/products/processors/cortex-a/cortex-a55 Differential Revision: https://reviews.llvm.org/D36731 llvm-svn: 311319
* Revert r311137 (GlobalISel ABI commit).Tim Northover2017-08-181-1/+1
| | | | | | | It was committed by mistake since it was in the same monorepo as the LLVM change I was working on. llvm-svn: 311140
* GlobalISel (AArch64): fix ABI at border between GPRs and SP.Tim Northover2017-08-171-1/+1
| | | | | | | | If a struct would end up half in GPRs and half on SP the ABI says it should actually go entirely on the stack. We were getting this wrong in GlobalISel before, causing compatibility issues. llvm-svn: 311137
* Update to use enum classes for various ARM *Kind enumsFlorian Hahn2017-07-271-8/+7
| | | | | | | | | | | | | | Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
* NetBSD uses soft-float by default, unless the environment is EABIHF orJoerg Sonnenberger2017-07-111-0/+12
| | | | | | GNUEABIHF. llvm-svn: 307665
* Update clang support for -mexecute-only/-mpure-code for backend change to ↵Eric Christopher2017-07-011-3/+1
| | | | | | use subtarget feature rather than command line option. llvm-svn: 306928
* [ARM] Add a driver option for +no-neg-immediatesSanne Wouda2017-03-271-0/+3
| | | | | | | | | | | | Reviewers: olista01, rengolin, javed.absar, samparker Reviewed By: samparker Subscribers: samparker, llvm-commits, aemerson Differential Revision: https://reviews.llvm.org/D31197 llvm-svn: 298850
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+544
Summary: (This is a move-only refactoring patch. There are no functionality changes.) This patch splits apart the Clang driver's tool and toolchain implementation files. Each target platform toolchain is moved to its own file, along with the closest-related tools. Each target platform toolchain has separate headers and implementation files, so the hierarchy of classes is unchanged. There are some remaining shared free functions, mostly from Tools.cpp. Several of these move to their own architecture-specific files, similar to r296056. Some of them are only used by a single target platform; since the tools and toolchains are now together, some helpers now live in a platform-specific file. The balance are helpers related to manipulating argument lists, so they are now in a new file pair, CommonArgs.h and .cpp. I've tried to cluster the code logically, which is fairly straightforward for most of the target platforms and shared architectures. I think I've made reasonable choices for these, as well as the various shared helpers; but of course, I'm happy to hear feedback in the review. There are some particular things I don't like about this patch, but haven't been able to find a better overall solution. The first is the proliferation of files: there are several files that are tiny because the toolchain is not very different from its base (usually the Gnu tools/toolchain). I think this is mostly a reflection of the true complexity, though, so it may not be "fixable" in any reasonable sense. The second thing I don't like are the includes like "../Something.h". I've avoided this largely by clustering into the current file structure. However, a few of these includes remain, and in those cases it doesn't make sense to me to sink an existing file any deeper. Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30372 llvm-svn: 297250
OpenPOWER on IntegriCloud