summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/Thumb1RegisterInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* In preparation for moving ARM's TargetRegisterInfo to the TargetMachineEric Christopher2015-03-121-576/+0
| | | | | | | merge Thumb1RegisterInfo and Thumb2RegisterInfo. This will enable us to match the TargetMachine for our TargetRegisterInfo classes. llvm-svn: 232117
* Remove the need to cache the subtarget in the ARM TargetRegisterInfoEric Christopher2015-03-121-11/+10
| | | | | | | classes. Replace the frame pointer initialization with a static function that'll look it up via the subtarget on the MachineFunction. llvm-svn: 232010
* Have TargetRegisterInfo::getLargestLegalSuperClass take aEric Christopher2015-03-101-4/+4
| | | | | | | MachineFunction argument so that it can look up the subtarget rather than using a cached one in some Targets. llvm-svn: 231888
* Migrate ARM except for TTI, AsmPrinter, and frame loweringEric Christopher2015-01-291-16/+6
| | | | | | away from getSubtargetImpl. llvm-svn: 227399
* [ARM] Remove dead assignment.Tilmann Scheller2014-12-191-1/+0
| | | | | | Found by the Clang static analyzer. llvm-svn: 224586
* [Thumb1] Re-write emitThumbRegPlusImmediateOliver Stannard2014-11-171-136/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This was motivated by a bug which caused code like this to be miscompiled: declare void @take_ptr(i8*) define void @test() { %addr1.32 = alloca i8 %addr2.32 = alloca i32, i32 1028 call void @take_ptr(i8* %addr1) ret void } This was emitting the following assembly to get the value of %addr1: add r0, sp, #1020 add r0, r0, #8 However, "add r0, r0, #8" is not a valid Thumb1 instruction, and this could not be assembled. The generated object file contained this, resulting in r0 holding SP+8 rather tha SP+1028: add r0, sp, #1020 add r0, sp, #8 This function looked like it could have caused miscompilations for other combinations of registers and offsets (though I don't think it is currently called with these), and the heuristic it used did not match the emitted code in all cases. llvm-svn: 222125
* [ARM] Remove another redundant assignment.Tilmann Scheller2014-11-051-1/+0
| | | | | | Found by the Clang static analyzer. llvm-svn: 221368
* ARM: rework Thumb1 frame index rewritingTim Northover2014-10-201-102/+11
| | | | | | | | | | | | | | | | | | | | | | | The previous code had a few problems, motivating the choices here. 1. It could create instructions clobbering CPSR, but the incoming MachineInstr didn't reflect this. A potential source of corruption. This is why the patch has a new PseudoInst for before lowering. 2. Similarly, there was some code to handle the incoming instruction not being ARMCC::AL, but this would have caused massive problems if it was actually invoked when a complex offset needing more than one instruction was requested. 3. It wasn't designed to handle unaligned pointers (or offsets). These should probably be minimised anyway, but the code needs to deal with them properly regardless. 4. It had some rather dubious ad-hoc code to avoid calling emitThumbRegPlusImmediate, a function which should be designed to do precisely this job. We seem to cover the common cases correctly now, and hopefully can enhance emitThumbRegPlusImmediate to handle any extra optimisations we need to add in future. llvm-svn: 220236
* [Thumb] Fix crash in Thumb1RegisterInfo::rewriteFrameIndexOliver Stannard2014-10-201-0/+1
| | | | | | | | | This function can, for some offsets from the SP, split one instruction into two. Since it re-uses the original instruction as the first instruction of the result, we need ensure its result register is not marked as dead before we use it in the second instruction. llvm-svn: 220194
* ARM: allow misaligned local variables in Thumb1 mode.Tim Northover2014-10-141-3/+1
| | | | | | | | There's no hard requirement on LLVM to align local variable to 32-bits, so the Thumb1 frame handling needs to be able to deal with variables that are only naturally aligned without falling over. llvm-svn: 219733
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-8/+4
| | | | | | | | | | | shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-7/+17
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Simplify resolveFrameIndex() signature.Jim Grosbach2014-04-021-4/+2
| | | | | | | | Just pass a MachineInstr reference rather than an MBB iterator. Creating a MachineInstr& is the first thing every implementation did anyway. llvm-svn: 205453
* Prune includes in ARM target.Craig Topper2014-03-221-2/+0
| | | | llvm-svn: 204548
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-1/+1
| | | | | | Remove the old functions. llvm-svn: 202636
* 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
OpenPOWER on IntegriCloud