summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [PowerPC] Use true offset value in "memrix" machine operandsUlrich Weigand2013-05-161-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of the change to always return "true" offset values from getPreIndexedAddressParts, tackling the case of "memrix" type operands. This is about instructions like LD/STD that only have a 14-bit field to encode immediate offsets, which are implicitly extended by two zero bits by the machine, so that in effect we can access 16-bit offsets as long as they are a multiple of 4. The PowerPC back end currently handles such instructions by carrying the 14-bit value (as it will get encoded into the actual machine instructions) in the machine operand fields for such instructions. This means that those values are in fact not the true offset, but rather the offset divided by 4 (and then truncated to an unsigned 14-bit value). Like in the case fixed in r182012, this makes common code operations on such offset values not work as expected. Furthermore, there doesn't really appear to be any strong reason why we should encode machine operands this way. This patch therefore changes the encoding of "memrix" type machine operands to simply contain the "true" offset value as a signed immediate value, while enforcing the rules that it must fit in a 16-bit signed value and must also be a multiple of 4. This change must be made simultaneously in all places that access machine operands of this type. However, just about all those changes make the code simpler; in many cases we can now just share the same code for memri and memrix operands. llvm-svn: 182032
* Removed dead code.Rafael Espindola2013-05-161-8/+4
| | | | llvm-svn: 181975
* PPC32: Fix stack collision between FP and CR save areas.Bill Schmidt2013-05-141-0/+1
| | | | | | | | | | | | | | | | | The changes to CR spill handling missed a case for 32-bit PowerPC. The code in PPCFrameLowering::processFunctionBeforeFrameFinalized() checks whether CR spill has occurred using a flag in the function info. This flag is only set by storeRegToStackSlot and loadRegFromStackSlot. spillCalleeSavedRegisters does not call storeRegToStackSlot, but instead produces MI directly. Thus we don't see the CR is spilled when assigning frame offsets, and the CR spill ends up colliding with some other location (generally the FP slot). This patch sets the flag in spillCalleeSavedRegisters for PPC32 so that the CR spill is properly detected and gets its own slot in the stack frame. llvm-svn: 181800
* Change getFrameMoves to return a const reference.Rafael Espindola2013-05-111-9/+7
| | | | | | | To add a frame now there is a dedicated addFrameMove which also takes care of constructing the move itself. llvm-svn: 181657
* Fix PPC64 CR spill location for callee-saved registersHal Finkel2013-04-151-35/+41
| | | | | | | | | | | | | | | | This fixes an ABI bug for non-Darwin PPC64. For the callee-saved condition registers, the spill location is specified relative to the stack pointer (SP + 8). However, this is not relative to the SP after the new stack frame is established, but instead relative to the caller's stack pointer (it is stored into the linkage area of the parent's stack frame). So, like with the link register, we don't directly spill the CRs with other callee-saved registers, but just mark them to be spilled during prologue generation. In practice, this reverts r179457 for PPC64 (but leaves it in place for PPC32). llvm-svn: 179500
* Mark all PPC CR registers to be spilled as live-in and tag MFCR appropriatelyHal Finkel2013-04-131-5/+14
| | | | | | | | | | | | Leaving MFCR has having unmodeled side effects is not enough to prevent unwanted instruction reordering post-RA. We could probably apply a stronger barrier attribute, but there is a better way: Add all (not just the first) CR to be spilled as live-in to the entry block, and add all CRs to the MFCR instruction as implicitly killed. Unfortunately, I don't have a small test case. llvm-svn: 179465
* Spill and restore PPC CR registers using the FP when we have oneHal Finkel2013-04-131-6/+14
| | | | | | | | | | For functions that need to spill CRs, and have dynamic stack allocations, the value of the SP during the restore is not what it was during the save, and so we need to use the FP in these cases (as for all of the other spills and restores, but the CR restore has a special code path because its reserved slot, like the link register, is specified directly relative to the adjusted SP). llvm-svn: 179457
* Cleanup PPC CR-spill kill flags and 32- vs. 64-bit instructionsHal Finkel2013-03-281-6/+6
| | | | | | | | There were a few places where kill flags were not being set correctly, and where 32-bit instruction variants were being used with 64-bit registers. After r178180, this code was being triggered causing llc to assert. llvm-svn: 178220
* PPC: Use HWEncoding and TRI->getEncodingValueHal Finkel2013-03-261-5/+7
| | | | | | | | | | | As pointed out by Jakob, we don't need to maintain a separate register-numbering table. Instead we should let TableGen generate the table for us from the information (already present) in PPCRegisterInfo.td. TRI->getEncodingValue is now used to access register-encoding values. No functionality change intended. llvm-svn: 178067
* Use multiple virtual registers in PPC CR spillingHal Finkel2013-03-261-0/+7
| | | | | | | | | | | | Now that the register scavenger can support multiple spill slots, and PEI can use virtual-register-based scavenging for multiple simultaneous registers, we can use a virtual register for the transfer register in the CR spilling code. This should eliminate the last place (outside of the prologue/epilogue) where we depend on the unconditional availability of the r0 register. We will soon be able to allocate it (in a somewhat restricted sense) as a GPR. llvm-svn: 178060
* Note in PPCFunctionInfo VRSAVE spillsHal Finkel2013-03-231-2/+7
| | | | | | | | | | | | In preparation for using the new register scavenger capability for providing more than one register simultaneously, specifically note functions that have spilled VRSAVE (currently, this can happen only in functions that use the setjmp intrinsic). As with CR spilling, such functions will need to provide two emergency spill slots to the scavenger. No functionality change intended. llvm-svn: 177832
* 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
* Correct PPC FRAMEADDR lowering using a pseudo-registerHal Finkel2013-03-211-0/+28
| | | | | | | | | | | | | | | | The old code used to lower FRAMEADDR tried to replicate the logic in the real frame-lowering code that determines whether or not the frame pointer (r31) will be used. When it seemed as through the frame pointer would not be used, the stack pointer (r1) was used instead. Unfortunately, because the stack size is not yet known, this does not work. Instead, this change introduces new always-reserved pseudo-registers (FP and FP8) that are replaced during prologue insertion with the real frame-pointer register (either r1 or r31). It is important that this intrinsic always return a valid frame address because it is used by Clang to store the frame address as part of code generation for __builtin_setjmp. llvm-svn: 177653
* Improve PPC VR (Altivec) register spillingHal Finkel2013-03-171-1/+6
| | | | | | | | | | | | | | | | This change cleans up two issues with Altivec register spilling: 1. The spilling code was inefficient (using two instructions, and add and a load, when just one would do) 2. The code assumed that r0 would always be available (true for now, but this will change) The new code handles VR spilling just like GPR spills but forced into r+r mode. As a result, when any VR spills are present, we must now always allocate the register-scavenger spill slot. llvm-svn: 177231
* Allocate the RS spill slot for any PPC function with spills and a large ↵Hal Finkel2013-03-151-31/+57
| | | | | | | | | | | | | | | | stack frame For spills into a large stack frame, the FI-elimination code uses the register scavenger to obtain a free GPR for use with an r+r-addressed load or store. When there are no available GPRs, the scavenger gets one by using its spill slot. Previously, we were not always allocating that spill slot and the RS would assert when the spill slot was needed. I don't currently have a small test that triggered the assert, but I've created a small regression test that verifies that the spill slot is now added when the stack frame is sufficiently large. llvm-svn: 177140
* Provide the register scavenger to processFunctionBeforeFrameFinalizedHal Finkel2013-03-141-2/+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
* Not all PPC functions with a frame pointer need a RS spill slotHal Finkel2013-03-141-1/+1
| | | | | | | | | | | | | We used to add a spill slot for the register scavenger whenever the function has a frame pointer. This is unnecessarily conservative: We may need the spill slot for dynamic stack allocations, and functions with dynamic stack allocations always have a FP, but we might also have a FP for other reasons (such as the user explicitly disabling frame-pointer elimination), and we don't necessarily need a spill slot for those functions. The structsinregs test needed adjustment because it disables FP elimination. llvm-svn: 177106
* Fix PR15332 (patch by Florian Zeitz).Bill Schmidt2013-02-261-4/+5
| | | | | | | | There's no need to generate a stack frame for PPC32 SVR4 when there are no local variables assigned to the stack, i.e., when no red zone is needed. (PPC64 supports a red zone, but PPC32 does not.) llvm-svn: 176124
* Fix PR14364.Bill Schmidt2013-02-241-1/+12
| | | | | | | | | | | This removes a const_cast hack from PPCRegisterInfo::hasReservedSpillSlot(). The proper place to save the frame index for the CR spill slot is in the PPCFunctionInfo object, not the PPCRegisterInfo object. No new test cases, as this just reimplements existing function. Existing tests such as test/CodeGen/PowerPC/crsave.ll are sufficient. llvm-svn: 175998
* Move the eliminateCallFramePseudoInstr method from TargetRegisterInfoEli Bendersky2013-02-211-0/+41
| | | | | | | | | | | | | | | 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
* Avoid using MRI::liveout_iterator for computing VRSAVEs.Jakob Stoklund Olesen2013-02-051-6/+15
| | | | | | | | | | The liveout lists are about to be removed from MRI, this is the only place they were used after register allocation. Get the live out V registers directly from the return instructions instead. llvm-svn: 174399
* 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
* Remove the Function::getFnAttributes method in favor of using the AttributeSetBill Wendling2012-12-301-3/+4
| | | | | | | | | directly. This is in preparation for removing the use of the 'Attribute' class as a collection of attributes. That will shift to the AttributeSet class instead. llvm-svn: 171253
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-2/+2
| | | | | | single attribute in the future. llvm-svn: 170502
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-2/+2
| | | | | | | | | | | | | | | | | 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
* The PowerPC VRSAVE register has been somewhat of an odd beast sinceBill Schmidt2012-10-101-5/+11
| | | | | | | | | | | | | | | | | the Altivec extensions were introduced. Its use is optional, and allows the compiler to communicate to the operating system which vector registers should be saved and restored during a context switch. In practice, this information is ignored by the various operating systems using the SVR4 ABI; the kernel saves and restores the entire register state. Setting the VRSAVE register is no longer performed by the AIX XL compilers, the IBM i compilers, or by GCC on Power Linux systems. It seems best to avoid this logic within LLVM as well. This patch avoids generating code to update and restore VRSAVE for the PowerPC SVR4 ABIs (32- and 64-bit). The code remains in place for the Darwin ABI. llvm-svn: 165656
* Create enums for the different attributes.Bill Wendling2012-10-091-2/+3
| | | | | | | We use the enums to query whether an Attributes object has that attribute. The opaque layer is responsible for knowing where that specific attribute is stored. llvm-svn: 165488
* Remove the `hasFnAttr' method from Function.Bill Wendling2012-09-261-2/+2
| | | | | | | The hasFnAttr method has been replaced by querying the Attributes explicitly. No intended functionality change. llvm-svn: 164725
* This patch corrects logic in PPCFrameLowering for save and restore of ↵Roman Divacky2012-09-121-17/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | nonvolatile condition register fields across calls under the SVR4 ABIs. * With the 64-bit ABI, the save location is at a fixed offset of 8 from the stack pointer. The frame pointer cannot be used to access this portion of the stack frame since the distance from the frame pointer may change with alloca calls. * With the 32-bit ABI, the save location is just below the general register save area, and is accessed via the frame pointer like the rest of the save areas. This is an optional slot, so it must only be created if any of CR2, CR3, and CR4 were modified. * For both ABIs, save/restore logic is generated only if one of the nonvolatile CR fields were modified. I also took this opportunity to clean up an extra FIXME in PPCFrameLowering.h. Save area offsets for 32-bit GPRs are meaningless for the 64-bit ABI, so I removed them for correctness and efficiency. Fixes PR13708 and partially also PR13623. It lets us enable exception handling on PPC64. Patch by William J. Schmidt! llvm-svn: 163713
* Add support for generating reg+reg preinc stores on PPC.Hal Finkel2012-06-191-8/+8
| | | | | | PPC will now generate STWUX and friends. llvm-svn: 158698
* Add a FIXME about access to negative stack-pointer offsets on PPC32.Hal Finkel2012-05-191-0/+2
| | | | | | | | | | | | | | The current code will generate a prologue which starts with something like: mflr 0 stw 31, -4(1) stw 0, 4(1) stwu 1, -16(1) But under the PPC32 SVR4 ABI, access to negative offsets from R1 is not allowed. This was pointed out by Peter Bergner. llvm-svn: 157133
* Convert some uses of XXXRegisterClass to &XXXRegClass. No functional change ↵Craig Topper2012-04-201-11/+11
| | | | | | since they are equivalent. llvm-svn: 155186
* Use uint16_t to store registers and opcode in static tables in the target ↵Craig Topper2012-03-111-1/+1
| | | | | | specific backends. llvm-svn: 152537
* 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
* Cleanup stack/frame register define/kill states. This fixes two bugs:Hal Finkel2011-12-301-8/+8
| | | | | | | | 1. The ST*UX instructions that store and update the stack pointer did not set define/kill on R1. This became a problem when I activated post-RA scheduling (and had incorrectly adjusted the Frames-large test). 2. eliminateFrameIndex did not kill its scavenged temporary register, and this could cause the scavenger to exhaust all available registers (and its emergency spill slot) when there were a lot of CR values to spill. The 2010-02-12-saveCR test has been adjusted to check for this. llvm-svn: 147359
* Add bundle aware API for querying instruction properties and switch the codeEvan Cheng2011-12-071-1/+1
| | | | | | | | | | | | | | 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
* enable PPC register scavenging by default (update tests and remove some FIXMEs)Hal Finkel2011-12-051-1/+1
| | | | llvm-svn: 145819
* Move global variables in TargetMachine into new TargetOptions class. As an APINick Lewycky2011-12-021-5/+9
| | | | | | | | | | | | change, now you need a TargetOptions object to create a TargetMachine. Clang patch to follow. One small functionality change in PTX. PTX had commented out the machine verifier parts in their copy of printAndVerify. That now calls the version in LLVMTargetMachine. Users of PTX who need verification disabled should rely on not passing the command-line flag to enable it. llvm-svn: 145714
* PPC: Disable moves for all CR subregisters.Benjamin Kramer2011-10-291-3/+1
| | | | | | Should fix assertion failures on ppc buildbots. llvm-svn: 143290
* Refactor PPC target to separate MC routines from Target routines.Evan Cheng2011-07-251-5/+5
| | | | llvm-svn: 135942
* Move getInitialFrameState from TargetFrameInfo to MCAsmInfo (suggestions forEvan Cheng2011-07-181-7/+0
| | | | | | better location welcome). llvm-svn: 135438
* Use the dwarf->llvm mapping to print register names in the cfiRafael Espindola2011-05-301-0/+8
| | | | | | | | directives. Fixes PR9826. llvm-svn: 132317
* Replace the -unwind-tables option with a per function flag. This is moreRafael Espindola2011-05-251-2/+1
| | | | | | | LTO friendly as we can now correctly merge files compiled with or without -fasynchronous-unwind-tables. llvm-svn: 132033
* Teach frame lowering to ignore debug values after the terminators.Jakob Stoklund Olesen2011-01-131-7/+8
| | | | llvm-svn: 123399
* Rename TargetFrameInfo into TargetFrameLowering. Also, put couple of FIXMEs ↵Anton Korobeynikov2011-01-101-0/+970
and fixes here and there. llvm-svn: 123170
OpenPOWER on IntegriCloud