summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders2019-08-151-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned& Depends on D65919 Reviewers: arsenm, bogner, craig.topper, RKSimon Reviewed By: arsenm Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65962 llvm-svn: 369041
* 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
* [Sparc] Fix typo. NFC.Jim Lin2019-04-151-2/+2
| | | | llvm-svn: 358370
* [Sparc] Fix incorrect MI insertion position for spilling f128.Jim Lin2019-04-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Obviously, new built MI (sethi+add or sethi+xor+add) for constructing large offset should be inserted before new created MI for storing even register into memory. So the insertion position should be *StMI instead of II. before fixed: std %f0, [%g1+80] sethi 4, %g1 <<< add %g1, %sp, %g1 <<< this two instructions should be put before "std %f0, [%g1+80]". sethi 4, %g1 add %g1, %sp, %g1 std %f2, [%g1+88] after fixed: sethi 4, %g1 add %g1, %sp, %g1 std %f0, [%g1+80] sethi 4, %g1 add %g1, %sp, %g1 std %f2, [%g1+88] Reviewers: venkatra, jyknight Reviewed By: jyknight Subscribers: jyknight, fedor.sergeev, jrtc27, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60397 llvm-svn: 358042
* 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
* [Sparc] Add support for the cycle counter available in GR740Daniel Cederman2018-08-271-0/+4
| | | | | | | | | | | | | | | | | Summary: The GR740 provides an up cycle counter in the registers ASR22 and ASR23. As these registers can not be read together atomically we only use the value of ASR23 for llvm.readcyclecounter(). The ASR23 register holds the 32 LSBs of the up-counter. Reviewers: jyknight, venkatra Reviewed By: jyknight Subscribers: jfb, fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D48638 llvm-svn: 340733
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-081-1/+1
| | | | | | | | This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
* Pass DebugLoc and SDLoc by const ref.Benjamin Kramer2016-06-121-7/+3
| | | | | | | | This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operations. No functionality change intended. llvm-svn: 272512
* [Sparc] Support user-specified stack object overalignment.James Y Knight2015-08-211-18/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Sparc] Implement i64 load/store support for 32-bit sparc.James Y Knight2015-08-101-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LDD/STD instructions can load/store a 64bit quantity from/to memory to/from a consecutive even/odd pair of (32-bit) registers. They are part of SparcV8, and also present in SparcV9. (Although deprecated there, as you can store 64bits in one register). As recommended on llvmdev in the thread "How to enable use of 64bit load/store for 32bit architecture" from Apr 2015, I've modeled the 64-bit load/store operations as working on a v2i32 type, rather than making i64 a legal type, but with few legal operations. The latter does not (currently) work, as there is much code in llvm which assumes that if i64 is legal, operations like "add" will actually work on it. The same assumption does not hold for v2i32 -- for vector types, it is workable to support only load/store, and expand everything else. This patch: - Adds a new register class, IntPair, for even/odd pairs of registers. - Modifies the list of reserved registers, the stack spilling code, and register copying code to support the IntPair register class. - Adds support in AsmParser. (note that in asm text, you write the name of the first register of the pair only. So the parser has to morph the single register into the equivalent paired register). - Adds the new instructions themselves (LDD/STD/LDDA/STDA). - Hooks up the instructions and registers as a vector type v2i32. Adds custom legalizer to transform i64 load/stores into v2i32 load/stores and bitcasts, so that the new instructions can actually be generated, and marks all operations other than load/store on v2i32 as needing to be expanded. - Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG. This hack undoes the transformation of i64 operands into two arbitrarily-allocated separate i32 registers in SelectionDAGBuilder. and instead passes them in a single IntPair. (Arbitrarily allocated registers are not useful, asm code expects to be receiving a pair, which can be passed to ldd/std.) Also adds a bunch of test cases covering all the bugs I've added along the way. Differential Revision: http://reviews.llvm.org/D8713 llvm-svn: 244484
* Remove the need to cache the subtarget in the Sparc TargetRegisterInfoEric Christopher2015-03-121-5/+6
| | | | | | classes. llvm-svn: 232013
* Have getCallPreservedMask and getThisCallPreservedMask take aEric Christopher2015-03-111-2/+3
| | | | | | | MachineFunction argument so that we can grab subtarget specific features off of it. llvm-svn: 231979
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-6/+3
| | | | | | | | | | | 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-3/+6
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [cleanup] Lift using directives, DEBUG_TYPE definitions, and even someChandler Carruth2014-04-221-2/+2
| | | | | | | | | | | | system headers above the includes of generated '.inc' files that actually contain code. In a few targets this was already done pretty consistently, but it wasn't done *really* consistently anywhere. It is strictly cleaner IMO and necessary in a bunch of places where the DEBUG_TYPE is referenced from the generated code. Consistency with the necessary places trumps. Hopefully the build bots are OK with the movement of intrin.h... llvm-svn: 206838
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-2/+2
| | | | llvm-svn: 205610
* [Sparc] Set %o7 as the return address register instead of %i7 in ↵Venkatraman Govindaraju2014-02-011-1/+1
| | | | | | MCRegisterInfo. Also, add CFI instructions to initialize the frame correctly. llvm-svn: 200617
* [Sparc] Emit large negative adjustments to SP/FP with sethi+xor instead of ↵Venkatraman Govindaraju2013-11-241-7/+34
| | | | | | sethi+or. This generates correct code for both sparc32 and sparc64. llvm-svn: 195576
* Remove getEHExceptionRegister and getEHHandlerRegister.Rafael Espindola2013-10-071-7/+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/+5
| | | | | | | | | | | | 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
* [Sparc] Implement spill and load for long double(f128) registers.Venkatraman Govindaraju2013-09-021-18/+59
| | | | llvm-svn: 189768
* [Sparc] Added V9's extra floating point registers and their aliases.Venkatraman Govindaraju2013-08-251-0/+9
| | | | llvm-svn: 189195
* Add an OtherPreserved field to the CalleeSaved TableGen class.Jakob Stoklund Olesen2013-08-231-2/+6
| | | | | | | | | | 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-3/+3
| | | | | | | | the internals of TargetMachine could change. No functionality change intended. llvm-svn: 183565
* Sparc: No functionality change. Cleanup whitespaces, comment formatting etc.,Venkatraman Govindaraju2013-06-041-4/+4
| | | | llvm-svn: 183243
* [Sparc] Generate correct code for leaf functions with stack objects Venkatraman Govindaraju2013-06-011-1/+8
| | | | llvm-svn: 183067
* [Sparc] Add support for leaf functions in sparc backend. Venkatraman Govindaraju2013-05-291-3/+5
| | | | llvm-svn: 182822
* [Sparc] Rearrange integer registers' allocation order so that register ↵Venkatraman Govindaraju2013-05-191-4/+16
| | | | | | | | allocator will use I and G registers before using L and O registers. Also, enable registers %g2-%g4 to be used in application and %g5 in 64 bit mode. llvm-svn: 182219
* SPARC v9 stack pointer bias.Jakob Stoklund Olesen2013-04-061-2/+3
| | | | | | | | | | | 64-bit SPARC v9 processes use biased stack and frame pointers, so the current function's stack frame is located at %sp+BIAS .. %fp+BIAS where BIAS = 2047. This makes more local variables directly accessible via [%fp+simm13] addressing. llvm-svn: 178965
* Add an I64Regs register class for 64-bit registers.Jakob Stoklund Olesen2013-04-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move the eliminateCallFramePseudoInstr method from TargetRegisterInfoEli Bendersky2013-02-211-13/+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-13/+8
| | | | | | | 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-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
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-5/+5
| | | | | | | | | | | | | | | | | 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
* Remove empty overrides of processFunctionBeforeFrameFinalized().Roman Divacky2012-08-061-3/+0
| | | | llvm-svn: 161328
* Reorder includes in Target backends to following coding standards. Remove ↵Craig Topper2012-03-171-2/+2
| | | | | | some superfluous forward declarations. llvm-svn: 152997
* Use uint16_t to store registers in callee saved register tables to reduce ↵Craig Topper2012-03-041-2/+2
| | | | | | 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
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-2/+0
| | | | llvm-svn: 148578
* Move getInitialFrameState from TargetFrameInfo to MCAsmInfo (suggestions forEvan Cheng2011-07-181-1/+0
| | | | | | better location welcome). llvm-svn: 135438
* Sink getDwarfRegNum, getLLVMRegNum, getSEHRegNum from TargetRegisterInfo downEvan Cheng2011-07-181-13/+1
| | | | | | | | | 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
* Next round of MC refactoring. This patch factor MC table instantiations, MCEvan Cheng2011-07-141-1/+0
| | | | | | registeration and creation code into XXXMCDesc libraries. llvm-svn: 135184
* Move CallFrameSetupOpcode and CallFrameDestroyOpcode to TargetInstrInfo.Evan Cheng2011-06-281-2/+1
| | | | llvm-svn: 134030
* Hide more details in tablegen generated MCRegisterInfo ctor function.Evan Cheng2011-06-281-2/+1
| | | | llvm-svn: 134027
* Merge XXXGenRegisterDesc.inc XXXGenRegisterNames.inc XXXGenRegisterInfo.h.incEvan Cheng2011-06-271-1/+4
| | | | | | into XXXGenRegisterInfo.inc. llvm-svn: 133922
* Starting to refactor Target to separate out code that's needed to fully describeEvan Cheng2011-06-241-4/+4
| | | | | | | | | | | | target machine from those that are only needed by codegen. The goal is to sink the essential target description into MC layer so we can start building MC based tools without needing to link in the entire codegen. First step is to refactor TargetRegisterInfo. This patch added a base class MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to separate register description from the rest of the stuff. llvm-svn: 133782
* Remove custom allocation order boilerplate that is no longer needed.Jakob Stoklund Olesen2011-06-091-0/+2
| | | | | | | | | | | | | | | | | | | | The register allocators automatically filter out reserved registers and place the callee saved registers last in the allocation order, so custom methods are no longer necessary just for that. Some targets still use custom allocation orders: ARM/Thumb: The high registers are removed from GPR in thumb mode. The NEON allocation orders prefer to use non-VFP2 registers first. X86: The GR8 classes omit AH-DH in x86-64 mode to avoid REX trouble. SystemZ: Some of the allocation orders are omitting R12 aliases without explanation. I don't understand this target well enough to fix that. It looks like all the boilerplate could be removed by reserving the right registers. llvm-svn: 132781
* Use the dwarf->llvm mapping to print register names in the cfiRafael Espindola2011-05-301-0/+4
| | | | | | | | directives. Fixes PR9826. llvm-svn: 132317
* Move hasFP() and few related hooks to TargetFrameInfo.Anton Korobeynikov2010-11-181-4/+0
| | | | llvm-svn: 119740
* First step of huge frame-related refactoring: move emit{Prologue,Epilogue} ↵Anton Korobeynikov2010-11-151-49/+0
| | | | | | out of TargetRegisterInfo to TargetFrameInfo, which is definitely much better suitable place llvm-svn: 119097
OpenPOWER on IntegriCloud