summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMCallingConv.h
Commit message (Collapse)AuthorAgeFilesLines
* Update to use new name alignTo().Rui Ueyama2016-01-141-1/+1
| | | | llvm-svn: 257804
* Replace uint16_t with the MCPhysReg typedef in many places. A lot of ↵Craig Topper2015-12-051-9/+9
| | | | | | physical register arrays already use this typedef. llvm-svn: 254843
* ARM: add backend support for the ABI used in WatchOSTim Northover2015-10-281-1/+3
| | | | | | | At the LLVM level this ABI is essentially a minimal modification of AAPCS to support 16-byte alignment for vector types and the stack. llvm-svn: 251570
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* ARM: treat [N x i32] and [N x i64] as AAPCS composite typesTim Northover2015-02-241-56/+91
| | | | | | | | | | | The logic is almost there already, with our special homogeneous aggregate handling. Tweaking it like this allows front-ends to emit AAPCS compliant code without ever having to count registers or add discarded padding arguments. Only arrays of i32 and i64 are needed to model AAPCS rules, but I decided to apply the logic to all integer arrays for more consistency. llvm-svn: 230348
* CodeGen: convert CCState interface to using ArrayRefsTim Northover2015-02-211-5/+5
| | | | | | | | | | | Everyone except R600 was manually passing the length of a static array at each callsite, calculated in a variety of interesting ways. Far easier to let ArrayRef handle that. There should be no functional change, but out of tree targets may have to tweak their calls as with these examples. llvm-svn: 230118
* Stop using ArrayRef of a const type.Tim Northover2014-11-271-1/+1
| | | | | | I *think* this is what the GCC bots are complaining about. llvm-svn: 222905
* AArch64: treat [N x Ty] as a block during procedure calls.Tim Northover2014-11-271-6/+2
| | | | | | | | | | | | | | The AAPCS treats small structs and homogeneous floating (or vector) aggregates specially, and guarantees they either get passed as a contiguous block of registers, or prevent any future use of those registers and get passed on the stack. This concept can fit quite neatly into LLVM's own type system, mapping an HFA to [N x float] and so on, and small structs to [N x i64]. Doing so allows front-ends to emit AAPCS compliant code without having to duplicate the register counting logic. llvm-svn: 222903
* [ARM] Enable DP copy, load and store instructions for FPv4-SPOliver Stannard2014-08-211-13/+4
| | | | | | | | | | | | | | | | | The FPv4-SP floating-point unit is generally referred to as single-precision only, but it does have double-precision registers and load, store and GPR<->DPR move instructions which operate on them. This patch enables the use of these registers, the main advantage of which is that we now comply with the AAPCS-VFP calling convention. This partially reverts r209650, which added some AAPCS-VFP support, but did not handle return values or alignment of double arguments in registers. This patch also adds tests for Thumb2 code generation for floating-point instructions and intrinsics, which previously only existed for ARM. llvm-svn: 216172
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* ARM: teach AAPCS-VFP to deal with Cortex-M4.Tim Northover2014-05-271-4/+13
| | | | | | | | | | | Cortex-M4 only has single-precision floating point support, so any LLVM "double" type will have been split into 2 i32s by now. Fortunately, the consecutive-register framework turns out to be precisely what's needed to reconstruct the double and follow AAPCS-VFP correctly! rdar://problem/17012966 llvm-svn: 209650
* ARM: HFAs must be passed in consecutive registersOliver Stannard2014-05-091-0/+90
| | | | | | | | | | When using the ARM AAPCS, HFAs (Homogeneous Floating-point Aggregates) must be passed in a block of consecutive floating-point registers, or on the stack. This means that unused floating-point registers cannot be back-filled with part of an HFA, however this can currently happen. This patch, along with the corresponding clang patch (http://reviews.llvm.org/D3083) prevents this. llvm-svn: 208413
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-7/+7
| | | | llvm-svn: 205610
* Fix for 5.5 Parameter Passing --> Stage C:Stepan Dyatkovskiy2013-04-221-0/+6
| | | | | | | | | | | | | | | -- C.4 and C.5 statements, when NSAA is not equal to SP. -- C.1.cp statement for VA functions. Note: There are no VFP CPRCs in a variadic procedure. Before this patch "NSAA != 0" means "don't use GPRs anymore ". But there are some exceptions in AAPCS. 1. For non VA function: allocate all VFP regs for CPRC. When all VFPs are allocated CPRCs would be sent to stack, while non CPRCs may be still allocated in GRPs. 2. Check that for VA functions all params uses GPRs and then stack. No exceptions, no CPRCs here. llvm-svn: 180011
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Prune includes and replace uses of ARMRegisterInfo.h with ARMBaeRegisterInfo.hCraig Topper2012-03-261-1/+0
| | | | llvm-svn: 153422
* Reorder includes to match coding standards. Fix an issue or two exposed by that.Craig Topper2012-03-171-4/+4
| | | | llvm-svn: 152978
* Convert more static tables of registers used by calling convention to ↵Craig Topper2012-03-111-6/+6
| | | | | | uint16_t to reduce space. llvm-svn: 152538
* Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, ↵Jia Liu2012-02-181-1/+1
| | | | | | MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
* In the calling convention logic, ValVT is always a legal type,Duncan Sands2010-11-041-7/+7
| | | | | | | and as such can be represented by an MVT - the more complicated EVT is not needed. Use MVT for ValVT everywhere. llvm-svn: 118245
* Inside the calling convention logic LocVT is always a simpleDuncan Sands2010-11-031-7/+7
| | | | | | | | | | value type, so there is no point in passing it around using an EVT. Use the simpler MVT everywhere. Rather than trying to propagate this information maximally in all the code that using the calling convention stuff, I chose to do a mainly low impact change instead. llvm-svn: 118167
* Newline at end of file.Eric Christopher2010-09-101-1/+1
| | | | llvm-svn: 113654
* Split out some of the calling convention bits so that they can beEric Christopher2010-09-101-0/+160
used for fast-isel. llvm-svn: 113652
OpenPOWER on IntegriCloud