summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Sparc/SparcRegisterInfo.h
Commit message (Collapse)AuthorAgeFilesLines
* CodeGen: Introduce a class for registersMatt Arsenault2019-06-241-1/+1
| | | | | | | | | Avoids using a plain unsigned for registers throughoug codegen. Doesn't attempt to change every register use, just something a little more than the set needed to build after changing the return type of MachineOperand::getReg(). llvm-svn: 364191
* 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
* [TargetRegisterInfo] Remove temporary hook enableMultipleCopyHints()Jonas Paulsson2018-10-051-2/+0
| | | | | | | | | | | | Finally all targets are enabling multiple regalloc hints, so the hook to disable this can now be removed. NFC. Review: Simon Pilgrim https://reviews.llvm.org/D52316 llvm-svn: 343851
* [Sparc] Return true in enableMultipleCopyHints().Jonas Paulsson2018-02-241-0/+2
| | | | | | | | | | Enable multiple COPY hints to eliminate more COPYs during register allocation. Note that this is something all targets should do, see https://reviews.llvm.org/D38128. Review: James Y Knight llvm-svn: 326028
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-1/+1
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* [sparc] Remove some unused (and undefined) declarations.Benjamin Kramer2016-05-271-3/+0
| | | | | | No functionality change. llvm-svn: 270981
* [Sparc] Support user-specified stack object overalignment.James Y Knight2015-08-211-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note: I do not implement a base pointer, so it's still impossible to have dynamic realignment AND dynamic alloca in the same function. This also moves the code for determining the frame index reference into getFrameIndexReference, where it belongs, instead of inline in eliminateFrameIndex. [Begin long-winded screed] Now, stack realignment for Sparc is actually a silly thing to support, because the Sparc ABI has no need for it -- unlike the situation on x86, the stack is ALWAYS aligned to the required alignment for the CPU instructions: 8 bytes on sparcv8, and 16 bytes on sparcv9. However, LLVM unfortunately implements user-specified overalignment using stack realignment support, so for now, I'm going to go along with that tradition. GCC instead treats objects which have alignment specification greater than the maximum CPU-required alignment for the target as a separate block of stack memory, with their own virtual base pointer (which gets aligned). Doing it that way avoids needing to implement per-target support for stack realignment, except for the targets which *actually* have an ABI-specified stack alignment which is too small for the CPU's requirements. Further unfortunately in LLVM, the default canRealignStack for all targets effectively returns true, despite that implementing that is something a target needs to do specifically. So, the previous behavior on Sparc was to silently ignore the user's specified stack alignment. Ugh. Yet MORE unfortunate, if a target actually does return false from canRealignStack, that also causes the user-specified alignment to be *silently ignored*, rather than emitting an error. (I started looking into fixing that last, but it broke a bunch of tests, because LLVM actually *depends* on having it silently ignored: some architectures (e.g. non-linux i386) have smaller stack alignment than spilled-register alignment. But, the fact that a register needs spilling is not known until within the register allocator. And by that point, the decision to not reserve the frame pointer has been frozen in place. And without a frame pointer, stack realignment is not possible. So, canRealignStack() returns false, and needsStackRealignment() then returns false, assuming everyone can just go on their merry way assuming the alignment requirements were probably just suggestions after-all. Sigh...) Differential Revision: http://reviews.llvm.org/D12208 llvm-svn: 245668
* Remove some unnecessary forward declarations and put a couple moreEric Christopher2015-03-121-4/+0
| | | | | | where they're supposed to reside. llvm-svn: 232014
* Remove the need to cache the subtarget in the Sparc TargetRegisterInfoEric Christopher2015-03-121-4/+1
| | | | | | classes. llvm-svn: 232013
* Have getCallPreservedMask and getThisCallPreservedMask take aEric Christopher2015-03-111-1/+2
| | | | | | | MachineFunction argument so that we can grab subtarget specific features off of it. llvm-svn: 231979
* Have getCalleeSavedRegs take a non-null MachineFunction all theEric Christopher2015-03-111-2/+1
| | | | | | | | time. The target independent code was passing in one all the time and targets weren't checking validity before using. Update a few calls to pass in a MachineFunction where necessary. llvm-svn: 231970
* 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
* [C++11] Add 'override' keywords and remove 'virtual'. Additionally add ↵Craig Topper2014-04-291-6/+7
| | | | | | 'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. Sparc edition llvm-svn: 207502
* [C++] Use 'nullptr'.Craig Topper2014-04-281-3/+3
| | | | llvm-svn: 207394
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-1/+1
| | | | llvm-svn: 205610
* Remove getEHExceptionRegister and getEHHandlerRegister.Rafael Espindola2013-10-071-4/+0
| | | | | | They haven't been used for a long time. Patch by MathOnNapkins. llvm-svn: 192099
* [Sparc] Correctly handle call to functions with ReturnsTwice attribute.Venkatraman Govindaraju2013-09-051-0/+2
| | | | | | | | | | | | In sparc, setjmp stores only the registers %fp, %sp, %i7 and %o7. longjmp restores the stack, and the callee-saved registers (all local/in registers: %i0-%i7, %l0-%l7) using the stored %fp and register windows. However, this does not guarantee that the longjmp will restore the registers, as they were when the setjmp was called. This is because these registers may be clobbered after returning from setjmp, but before calling longjmp. This patch prevents the registers %i0-%i5, %l0-l7 to live across the setjmp call using the register mask. llvm-svn: 190033
* Add an OtherPreserved field to the CalleeSaved TableGen class.Jakob Stoklund Olesen2013-08-231-0/+1
| | | | | | | | | | This field specifies registers that are preserved across function calls, but that should not be included in the generates SaveList array. This can be used ot generate regmasks for architectures that save registers through other means, like SPARC's register windows. llvm-svn: 189084
* Don't cache the instruction and register info from the TargetMachine, becauseBill Wendling2013-06-071-2/+1
| | | | | | | | the internals of TargetMachine could change. No functionality change intended. llvm-svn: 183565
* Add an I64Regs register class for 64-bit registers.Jakob Stoklund Olesen2013-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | We are going to use the same registers for 32-bit and 64-bit values, but in two different register classes. The I64Regs register class has a larger spill size and alignment. The addition of an i64 register class confuses TableGen's type inference, so it is necessary to clarify the type of some immediates and the G0 register. In 64-bit mode, pointers are i64 and should use the I64Regs register class. Implement getPointerRegClass() to dynamically provide the pointer register class depending on the subtarget. Use ptr_rc and iPTR for memory operands. Finally, add the i64 type to the IntRegs register class. This register class is not used to hold i64 values, I64Regs is for that. The type is required to appease TableGen's type checking in output patterns like this: def : Pat<(add i64:$a, i64:$b), (ADDrr $a, $b)>; SPARC v9 uses the same ADDrr instruction for i32 and i64 additions, and TableGen doesn't know to check the type of register sub-classes. llvm-svn: 178522
* Provide the register scavenger to processFunctionBeforeFrameFinalizedHal Finkel2013-03-141-1/+2
| | | | | | | | | | | | | Add the current PEI register scavenger as a parameter to the processFunctionBeforeFrameFinalized callback. This change is necessary in order to allow the PowerPC target code to set the register scavenger frame index after the save-area offset adjustments performed by processFunctionBeforeFrameFinalized. Only after these adjustments have been made is it possible to estimate the size of the stack frame. llvm-svn: 177108
* Move the eliminateCallFramePseudoInstr method from TargetRegisterInfoEli Bendersky2013-02-211-4/+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-1/+2
| | | | | | | Each target implementation was needlessly recomputing the index. Part of rdar://13076458 llvm-svn: 174083
* Use uint16_t to store registers in callee saved register tables to reduce ↵Craig Topper2012-03-041-1/+1
| | | | | | size of static data. llvm-svn: 151996
* 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
* Sink getDwarfRegNum, getLLVMRegNum, getSEHRegNum from TargetRegisterInfo downEvan Cheng2011-07-181-4/+0
| | | | | | | | | to MCRegisterInfo. Also initialize the mapping at construction time. This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step towards fixing the layering violation. llvm-svn: 135424
* Merge XXXGenRegisterDesc.inc XXXGenRegisterNames.inc XXXGenRegisterInfo.h.incEvan Cheng2011-06-271-1/+3
| | | | | | into XXXGenRegisterInfo.inc. llvm-svn: 133922
* Use the dwarf->llvm mapping to print register names in the cfiRafael Espindola2011-05-301-0/+1
| | | | | | | | directives. Fixes PR9826. llvm-svn: 132317
* Move hasFP() and few related hooks to TargetFrameInfo.Anton Korobeynikov2010-11-181-2/+0
| | | | llvm-svn: 119740
* First step of huge frame-related refactoring: move emit{Prologue,Epilogue} ↵Anton Korobeynikov2010-11-151-5/+2
| | | | | | out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place llvm-svn: 119097
* Simplify eliminateFrameIndex() interface back down now that PEI doesn't needJim Grosbach2010-08-261-3/+2
| | | | | | to try to re-use scavenged frame index reference registers. rdar://8277890 llvm-svn: 112241
* cleanupRafael Espindola2010-06-021-3/+0
| | | | llvm-svn: 105322
* Change the Value argument to eliminateFrameIndex to a type-tagged value. ThisJim Grosbach2010-03-091-1/+1
| | | | | | | | | | is preparatory to having PEI's scavenged frame index value reuse logic properly distinguish types of frame values (e.g., whether the value is stack-pointer relative or frame-pointer relative). No functionality change. llvm-svn: 98086
* Make the MachineFunction argument of getFrameRegister const.David Greene2009-11-121-1/+1
| | | | | | This also fixes a build error. llvm-svn: 87027
* Add register-reuse to frame-index register scavenging. When a target usesJim Grosbach2009-10-071-2/+3
| | | | | | | | | | | | | | | | | | | | a virtual register to eliminate a frame index, it can return that register and the constant stored there to PEI to track. When scavenging to allocate for those registers, PEI then tracks the last-used register and value, and if it is still available and matches the value for the next index, reuses the existing value rather and removes the re-materialization instructions. Fancier tracking and adjustment of scavenger allocations to keep more values live for longer is possible, but not yet implemented and would likely be better done via a different, less special-purpose, approach to the problem. eliminateFrameIndex() is modified so the target implementations can return the registers they wish to be tracked for reuse. ARM Thumb1 implements and utilizes the new mechanism. All other targets are simply modified to adjust for the changed eliminateFrameIndex() prototype. llvm-svn: 83467
* Move reMaterialize() from TargetRegisterInfo to TargetInstrInfo.Evan Cheng2008-03-311-3/+0
| | | | llvm-svn: 48995
* Rename MRegisterInfo to TargetRegisterInfo.Dan Gohman2008-02-101-2/+2
| | | | llvm-svn: 46930
* Move even more functionality from MRegisterInfo into TargetInstrInfo.Owen Anderson2008-01-071-10/+0
| | | | | | Some day I'll get it all moved over... llvm-svn: 45672
* Move some more instruction creation methods from RegisterInfo into InstrInfo.Owen Anderson2008-01-011-26/+1
| | | | llvm-svn: 45484
* Remove attribution from file headers, per discussion on llvmdev.Chris Lattner2007-12-291-2/+2
| | | | llvm-svn: 45418
* Add a argument to storeRegToStackSlot and storeRegToAddr to specify whetherEvan Cheng2007-12-051-2/+2
| | | | | | the stored register is killed. llvm-svn: 44600
* Remove redundant foldMemoryOperand variants and other code clean up.Evan Cheng2007-12-021-14/+2
| | | | llvm-svn: 44517
* Allow some reloads to be folded in multi-use cases. Specifically testl r, r ↵Evan Cheng2007-12-011-0/+12
| | | | | | -> cmpl [mem], 0. llvm-svn: 44479
* Add parameter to getDwarfRegNum to permit targetsDale Johannesen2007-11-131-1/+1
| | | | | | | | to use different mappings for EH and debug info; no functional change yet. Fix warning in X86CodeEmitter. llvm-svn: 44056
* Use TableGen to emit information for dwarf register numbers. Anton Korobeynikov2007-11-111-0/+2
| | | | | | | | This makes DwarfRegNum to accept list of numbers instead. Added three different "flavours", but only slightly tested on x86-32/linux. Please check another subtargets if possible, llvm-svn: 43997
* - Added getOpcodeAfterMemoryUnfold(). It doesn't unfold an instruction, but ↵Evan Cheng2007-10-181-2/+2
| | | | | | | | only returns the opcode of the instruction post unfolding. - Fix some copy+paste bugs. llvm-svn: 43153
* Use SmallVectorImpl instead of SmallVector with hardcoded size in MRegister ↵Evan Cheng2007-10-181-4/+4
| | | | | | public interface. llvm-svn: 43150
* - Added a few target hooks to generate load / store instructions from / to anyEvan Cheng2007-10-051-0/+10
| | | | | | | | address (not just from / to frameindexes). - Added target hooks to unfold load / store instructions / SDNodes into separate load, data processing, store instructions / SDNodes. llvm-svn: 42621
* Allow copyRegToReg to emit cross register classes copies.Evan Cheng2007-09-261-1/+2
| | | | | | Tested with "make check"! llvm-svn: 42346
* Add a variant of foldMemoryOperand to fold any load / store, not just load / ↵Evan Cheng2007-08-301-0/+6
| | | | | | store from / to stack slots. llvm-svn: 41597
OpenPOWER on IntegriCloud