summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/Thumb1RegisterInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* ARM: remove unnecessary state-tracking during frame lowering.Tim Northover2013-11-041-5/+1
| | | | | | | | | | | | | | | | | | | | | ResolveFrameIndex had what appeared to be a very nasty hack for when the frame-index referred to a callee-saved register. In this case it "adjusted" the offset so that the address was correct if (and only if) the MachineInstr immediately followed the respective push. This "worked" for all forms of GPR & DPR but was only ever used to set the frame pointer itself, and once this was put in a more sensible location the entire state-tracking machinery it relied on became redundant. So I stripped it. The only wrinkle is that "add r7, sp, #0" might theoretically be slower (need an actual ALU slot) compared to "mov r7, sp" so I added a micro-optimisation that also makes emitARMRegUpdate and emitT2RegUpdate also work when NumBytes == 0. No test changes since there shouldn't be any functionality change. llvm-svn: 194025
* Even more spelling fixes for "instruction".Robert Wilhelm2013-09-281-1/+1
| | | | llvm-svn: 191611
* Don't cache the instruction and register info from the TargetMachine, becauseBill Wendling2013-06-071-3/+9
| | | | | | the internals of TargetMachine could change. llvm-svn: 183488
* Allow the register scavenger to spill multiple registersHal Finkel2013-03-221-1/+1
| | | | | | | | | | | | | | | | | | This patch lets the register scavenger make use of multiple spill slots in order to guarantee that it will be able to provide multiple registers simultaneously. To support this, the RS's API has changed slightly: setScavengingFrameIndex / getScavengingFrameIndex have been replaced by addScavengingFrameIndex / isScavengingFrameIndex / getScavengingFrameIndices. In forthcoming commits, the PowerPC backend will use this capability in order to implement the spilling of condition registers, and some special-purpose registers, without relying on r0 being reserved. In some cases, spilling these registers requires two GPRs: one for addressing and one to hold the value being transferred. llvm-svn: 177774
* Move the eliminateCallFramePseudoInstr method from TargetRegisterInfoEli Bendersky2013-02-211-41/+0
| | | | | | | | | | | | | | | to TargetFrameLowering, where it belongs. Incidentally, this allows us to delete some duplicated (and slightly different!) code in TRI. There are potentially other layering problems that can be cleaned up as a result, or in a similar manner. The refactoring was OK'd by Anton Korobeynikov on llvmdev. Note: this touches the target interfaces, so out-of-tree targets may be affected. llvm-svn: 175788
* [PEI] Pass the frame index operand number to the eliminateFrameIndex function.Chad Rosier2013-01-311-15/+12
| | | | | | | Each target implementation was needlessly recomputing the index. Part of rdar://13076458 llvm-svn: 174083
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-4/+4
| | | | | | | | | | | | | | | | | | | | | 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
* Remove the explicit MachineInstrBuilder(MI) constructor.Jakob Stoklund Olesen2012-12-191-6/+3
| | | | | | | | | | | | | Use the version that also takes an MF reference instead. It would technically be possible to extract an MF reference from the MI as MI->getParent()->getParent(), but that would not work for MIs that are not inserted into any basic block. Given the reasonably small number of places this constructor was used at all, I preferred the compile time check to a run time assertion. llvm-svn: 170588
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-6/+6
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Add an MF argument to TRI::getPointerRegClass() and TII::getRegClass().Jakob Stoklund Olesen2012-05-071-1/+2
| | | | | | | | | | | | | The getPointerRegClass() hook can return register classes that depend on the calling convention of the current function (ptr_rc_tailcall). So far, we have been able to infer the calling convention from the subtarget alone, but as we add support for multiple calling conventions per target, that no longer works. Patch by Yiannis Tsiouris! llvm-svn: 156328
* Convert more uses of XXXRegisterClass to &XXXRegClass. No functional change ↵Craig Topper2012-04-201-4/+4
| | | | | | since they are equivalent. llvm-svn: 155188
* Reorder includes to match coding standards. Fix an issue or two exposed by that.Craig Topper2012-03-171-2/+1
| | | | llvm-svn: 152978
* Handle regmasks in Thumb1RegisterInfo::saveScavengerRegister().Jakob Stoklund Olesen2012-03-011-0/+5
| | | | | | | | | | | | | | This function could have r12 live across a function call when compiling thumb1 code. The test case for this is not included because it is very long. It must provoke emergency spilling near a function call. The behavior is provoked by MultiSource/Applications/JM/lencod, and it triggers an assertion in the scavenger. <rdar://problem/10963642> llvm-svn: 151855
* Enable ARM base pointer when calling functions with large arguments.Jakob Stoklund Olesen2012-02-281-0/+16
| | | | | | | | | | | | | | | | | | When an outgoing call takes more than 2k of arguments on the stack, we don't allocate that call frame in the prolog, but adjust the stack pointer immediately before the call instead. This causes problems with the emergency spill slot because PEI can't track stack pointer adjustments on the second pass, and if the outgoing arguments are too big, SP can't be used to reach the emergency spill slot at all. Work around these problems by ensuring there is a base or frame pointer that can be used to access the emergency spill slot. <rdar://problem/10917166> llvm-svn: 151604
* 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
* Convert assert(0) to llvm_unreachableCraig Topper2012-02-071-1/+1
| | | | llvm-svn: 149961
* Add bundle aware API for querying instruction properties and switch the codeEvan Cheng2011-12-071-4/+3
| | | | | | | | | | | | | | generator to it. For non-bundle instructions, these behave exactly the same as the MC layer API. For properties like mayLoad / mayStore, look into the bundle and if any of the bundled instructions has the property it would return true. For properties like isPredicable, only return true if *all* of the bundled instructions have the property. For properties like canFoldAsLoad, isCompare, conservatively return false for bundles. llvm-svn: 146026
* Fix a regression from r138445. If we're loading from the frame/base pointerChad Rosier2011-10-101-0/+1
| | | | | | | | the tADDrSPi instruction can't be used. Make sure we're updating the opcode to tADDi3 in all cases. rdar://10254707 llvm-svn: 141523
* Thumb1 ADD/SUB SP instructions are predicable in Thumb2 mode.Jim Grosbach2011-08-241-14/+6
| | | | | | | | | Add the predicate operand to the instructions. Update the back end accordingly where the instructions are used. Restrict the SP operands to actually only be SP, as otherwise these break assembly parsing for the normal instruction variants. llvm-svn: 138445
* 80 columns.Jim Grosbach2011-08-171-1/+2
| | | | llvm-svn: 137857
* Tidy up.Jim Grosbach2011-08-171-2/+1
| | | | llvm-svn: 137856
* Silence a bunch (but not all) "variable written but not read" warningsDuncan Sands2011-08-121-2/+2
| | | | | | when building with assertions disabled. llvm-svn: 137460
* Sink ARMMCExpr and ARMAddressingModes into MC layer. First step to separate ↵Evan Cheng2011-07-201-1/+1
| | | | | | ARM MC code from target. llvm-svn: 135636
* Move getInitialFrameState from TargetFrameInfo to MCAsmInfo (suggestions forEvan Cheng2011-07-181-1/+0
| | | | | | better location welcome). llvm-svn: 135438
* Refact ARM Thumb1 tMOVr instruction family.Jim Grosbach2011-06-301-3/+3
| | | | | | | | | | Merge the tMOVr, tMOVgpr2tgpr, tMOVtgpr2gpr, and tMOVgpr2gpr instructions into tMOVr. There's no need to keep them separate. Giving the tMOVr instruction the proper GPR register class for its operands is sufficient to give the register allocator enough information to do the right thing directly. llvm-svn: 134204
* Thumb1 register to register MOV instruction is predicable.Jim Grosbach2011-06-301-11/+11
| | | | | | | | | Fix a FIXME and allow predication (in Thumb2) for the T1 register to register MOV instructions. This allows some better codegen with if-conversion (as seen in the test updates), plus it lays the groundwork for pseudo-izing the tMOVCC instructions. llvm-svn: 134197
* Refactor away tSpill and tRestore pseudos in ARM backend.Jim Grosbach2011-06-291-5/+3
| | | | | | | The tSpill and tRestore instructions are just copies of the tSTRspi and tLDRspi instructions, respectively. Just use those directly instead. llvm-svn: 134092
* - Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo andEvan Cheng2011-06-281-8/+8
| | | | | | | | sink them into MC layer. - Added MCInstrInfo, which captures the tablegen generated static data. Chang TargetInstrInfo so it's based off MCInstrInfo. llvm-svn: 134021
* Use TRI::has{Sub,Super}ClassEq() where possible.Jakob Stoklund Olesen2011-06-021-1/+1
| | | | | | No functional change. llvm-svn: 132455
* Add a TRI::getLargestLegalSuperClass hook to provide an upper limit on ↵Jakob Stoklund Olesen2011-04-261-0/+8
| | | | | | | | | | | | register class inflation. The hook will be used by the register allocator when recomputing register classes after removing constraints. Thumb1 code doesn't allow anything larger than tGPR, and x86 needs to ensure that the spill size doesn't change. llvm-svn: 130228
* Trim a few unneeded includes.Jim Grosbach2011-04-181-2/+0
| | | | llvm-svn: 129723
* Provide a legal pointer register class when targeting thumb1.Jakob Stoklund Olesen2011-03-311-0/+5
| | | | | | The LocalStackSlotAllocation pass was creating illegal registers. llvm-svn: 128687
* In Thumb1 mode the constant might be materialized via the load from ↵Anton Korobeynikov2011-03-051-3/+3
| | | | | | constpool. Emit unwinding information in case when this load from constpool is used to change the stack pointer in the prologue. llvm-svn: 127105
* Implement frame unwinding information emission for Thumb1. Not finished yet ↵Anton Korobeynikov2011-03-051-25/+35
| | | | | | because there is no way given the constpool index to examine the actual entry: the reason is clones inserted by constant island pass, which are not tracked at all! The only connection is done during asmprinting time via magic label names which is really gross and needs to be eventually fixed. llvm-svn: 127104
* Preliminary support for ARM frame save directives emission via MI flags.Anton Korobeynikov2011-03-051-13/+13
| | | | | | | This is just very first approximation how the stuff should be done (e.g. ARM-only for now). More to follow. llvm-svn: 127101
* When updating a tSpill/tRestore instruction to be a tSTRr/tLDRr, correctlyJim Grosbach2011-01-131-4/+7
| | | | | | | | | set up the source operands. The original instr has an immediate operand that should be replaced with the frame reg operand rather than just adding the reg operand. Previously, the instruction ended up with too many operands causing an assert() when adding the default predicate. rdar://8825456 llvm-svn: 123387
* Rename TargetFrameInfo into TargetFrameLowering. Also, put couple of FIXMEs ↵Anton Korobeynikov2011-01-101-4/+4
| | | | | | and fixes here and there. llvm-svn: 123170
* If we're not using reg+reg offset we're using reg+imm, set the opcodeEric Christopher2010-12-211-2/+2
| | | | | | | | | to be the one we want to use. bugpoint reduced testcase is a little large, I'll see if I can simplify it down more. Fixes part of rdar://8782207 llvm-svn: 122307
* Add tSpill and tRestore to the opcodes to replace with tSTRi and tLDRiBill Wendling2010-12-161-0/+2
| | | | | | | | | respectively. It may be a bug that these opcodes are getting this far into machine code generation. llvm-svn: 121931
* Thumb1 had two patterns for the same load-from-constant-pool instruction.Jim Grosbach2010-12-151-1/+1
| | | | | | Canonicalize on tLDRpci and remove tLDRcp. llvm-svn: 121920
* If we're changing the frame register to a physical register other than SP, weBill Wendling2010-12-151-27/+37
| | | | | | need to use tLDRi and tSTRi instead of tLDRspi and tSTRspi respectively. llvm-svn: 121915
* The tLDR et al instructions were emitting either a reg/reg or reg/immBill Wendling2010-12-141-7/+4
| | | | | | | | | | | | | | | | instruction based on the t_addrmode_s# mode and what it returned. There is some obvious badness to this. In particular, it's hard to do MC-encoding when the instruction may change out from underneath you after the t_addrmode_s# variable is finally resolved. The solution is to revert a long-ago change that merged the reg/reg and reg/imm versions. There is the addition of several new addressing modes. They no longer have extraneous operands associated with them. I.e., if it's reg/reg we don't have to have a dummy zero immediate tacked on to the SDNode. There are some obvious cleanups here, which will happen shortly. llvm-svn: 121747
* Avoid release build warnings.Benjamin Kramer2010-11-191-2/+2
| | | | llvm-svn: 119804
* Move hasFP() and few related hooks to TargetFrameInfo.Anton Korobeynikov2010-11-181-15/+5
| | | | llvm-svn: 119740
* First step of huge frame-related refactoring: move emit{Prologue,Epilogue} ↵Anton Korobeynikov2010-11-151-203/+0
| | | | | | out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place llvm-svn: 119097
* Revert r114340 (improvements in Darwin function prologue/epilogue), as it brokeJim Grosbach2010-11-021-11/+27
| | | | | | assumptions about stack layout. Specifically, LR must be saved next to FP. llvm-svn: 118026
* Add a pre-dispatch SjLj EH hook on the unwind edge for targets to do anyJim Grosbach2010-10-191-8/+7
| | | | | | | setup they require. Use this for ARM/Darwin to rematerialize the base pointer from the frame pointer when required. rdar://8564268 llvm-svn: 116879
* Simplify ARM callee-saved register handling by removing the distinctionJim Grosbach2010-09-201-27/+11
| | | | | | | | | | | | | | | | | | | between the high and low registers for prologue/epilogue code. This was a Darwin-only thing that wasn't providing a realistic benefit anymore. Combining the save areas simplifies the compiler code and results in better ARM/Thumb2 codegen. For example, previously we would generate code like: push {r4, r5, r6, r7, lr} add r7, sp, #12 stmdb sp!, {r8, r10, r11} With this change, we combine the register saves and generate: push {r4, r5, r6, r7, r8, r10, r11, lr} add r7, sp, #12 rdar://8445635 llvm-svn: 114340
* Re-apply r112883:Jim Grosbach2010-09-031-3/+13
| | | | | | | | | | | | | | "For ARM stack frames that utilize variable sized objects and have either large local stack areas or require dynamic stack realignment, allocate a base register via which to access the local frame. This allows efficient access to frame indices not accessible via the FP (either due to being out of range or due to dynamic realignment) or the SP (due to variable sized object allocation). In particular, this greatly improves efficiency of access to spill slots in Thumb functions which contain VLAs." r112986 fixed a latent bug exposed by the above. llvm-svn: 112989
* Revert "For ARM stack frames that utilize variable sized objects and have ↵Daniel Dunbar2010-09-031-13/+3
| | | | | | | | either", it is breaking oggenc with Clang for ARMv6. This reverts commit 8d6e29cfda270be483abf638850311670829ee65. llvm-svn: 112962
OpenPOWER on IntegriCloud