summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/Arch/ARM.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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