summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add an MF argument to TRI::getPointerRegClass() and TII::getRegClass().Jakob Stoklund Olesen2012-05-071-2/+4
| | | | | | | | | | | | | 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
* Implement a bastardized ABI.Evan Cheng2012-04-271-2/+4
| | | | llvm-svn: 155686
* This patch fixes a problem which arose when using the Post-RA schedulerPreston Gurd2012-04-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on X86 Atom. Some of our tests failed because the tail merging part of the BranchFolding pass was creating new basic blocks which did not contain live-in information. When the anti-dependency code in the Post-RA scheduler ran, it would sometimes rename the register containing the function return value because the fact that the return value was live-in to the subsequent block had been lost. To fix this, it is necessary to run the RegisterScavenging code in the BranchFolding pass. This patch makes sure that the register scavenging code is invoked in the X86 subtarget only when post-RA scheduling is being done. Post RA scheduling in the X86 subtarget is only done for Atom. This patch adds a new function to the TargetRegisterClass to control whether or not live-ins should be preserved during branch folding. This is necessary in order for the anti-dependency optimizations done during the PostRASchedulerList pass to work properly when doing Post-RA scheduling for the X86 in general and for the Intel Atom in particular. The patch adds and invokes the new function trackLivenessAfterRegAlloc() instead of using the existing requiresRegisterScavenging(). It changes BranchFolding.cpp to call trackLivenessAfterRegAlloc() instead of requiresRegisterScavenging(). It changes the all the targets that implemented requiresRegisterScavenging() to also implement trackLivenessAfterRegAlloc(). It adds an assertion in the Post RA scheduler to make sure that post RA liveness information is available when it is needed. It changes the X86 break-anti-dependencies test to use –mcpu=atom, in order to avoid running into the added assertion. Finally, this patch restores the use of anti-dependency checking (which was turned off temporarily for the 3.1 release) for Intel Atom in the Post RA scheduler. Patch by Andy Zhang! Thanks to Jakob and Anton for their reviews. llvm-svn: 155395
* Convert more uses of XXXRegisterClass to &XXXRegClass. No functional change ↵Craig Topper2012-04-201-3/+3
| | | | | | since they are equivalent. llvm-svn: 155188
* Replace uses of ARMBaseInstrInfo and ARMTargetMachine with the Base versions.Craig Topper2012-03-251-1/+0
| | | | llvm-svn: 153421
* remove unused variableMatt Beaumont-Gay2012-03-201-1/+0
| | | | llvm-svn: 153116
* Require a base pointer for stack realignment when SP may vary dynamically.Bob Wilson2012-03-201-2/+3
| | | | | | | | | | | | | ARMBaseRegisterInfo::canRealignStack was checking for variable-sized objects but not for stack adjustments around calls. Use hasReservedCallFrame() to check for both. The hasBasePointer function was already correctly checking both conditions, so the effect of this was that a base pointer would be used without checking whether the base pointer register could be reserved. I don't have a small testcase for this. <rdar://problem/11075906> llvm-svn: 153110
* Remove some redundant checks.Bob Wilson2012-03-201-2/+1
| | | | | | | ARMFrameLowering::hasReservedCallFrame is already checking for variable sized objects, so there's no point in checking it twice. llvm-svn: 153109
* Reorder includes to match coding standards. Fix an issue or two exposed by that.Craig Topper2012-03-171-1/+1
| | | | llvm-svn: 152978
* Split fpscr into two registers: FPSCR and FPSCR_NZCV.Lang Hames2012-03-061-0/+1
| | | | | | | | | The fpscr register contains both flags (set by FP operations/comparisons) and control bits. The control bits (FPSCR) should be reserved, since they're always available and needn't be defined before use. The flag bits (FPSCR_NZCV) should like to be unreserved so they can be hoisted by MachineCSE. This fixes PR12165. llvm-svn: 152076
* Use uint16_t instead of unsigned to store registers in reg classes. Reduces ↵Craig Topper2012-03-041-13/+13
| | | | | | static data size. llvm-svn: 151998
* 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
* Enable ARM base pointer when calling functions with large arguments.Jakob Stoklund Olesen2012-02-281-1/+21
| | | | | | | | | | | | | | | | | | 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
* Remove extra semi-colons.Chad Rosier2012-02-221-1/+1
| | | | llvm-svn: 151169
* 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
* Re-enable 150652 and 150654 - Make FPSCR non-reserved, and make MachineCSE ↵Lang Hames2012-02-171-1/+0
| | | | | | bail on reserved registers. This *should* be safe as of r150786. llvm-svn: 150769
* Oop - r150653 + r150654 broke one of my test cases. Backing out for now...Lang Hames2012-02-161-0/+1
| | | | llvm-svn: 150655
* FPSCR shouldn't be reserved.Lang Hames2012-02-161-1/+0
| | | | llvm-svn: 150654
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-4/+0
| | | | llvm-svn: 148578
* Implement ARMBaseRegisterInfo::getCallPreservedMask().Jakob Stoklund Olesen2012-01-171-19/+5
| | | | | | Move ARM callee-saved lists into ARMCallingConv.td. llvm-svn: 148357
* Reapply r146997, "Heed spill slot alignment on ARM."Jakob Stoklund Olesen2012-01-051-1/+1
| | | | | | | | | | | | Now that canRealignStack() understands frozen reserved registers, it is safe to use it for aligned spill instructions. It will only return true if the registers reserved at the beginning of register allocation allow for dynamic stack realignment. <rdar://problem/10625436> llvm-svn: 147579
* Avoid reserving an ARM base pointer during register allocation.Jakob Stoklund Olesen2012-01-051-2/+17
| | | | | | | | | | | | | | | | | Once register allocation has started the reserved registers are frozen. Fix the ARM canRealignStack() hook to respect the frozen register state. Now the hook returns false if register allocation was started with frame pointer elimination enabled. It also returns false if register allocation started without a reserved base pointer, and stack realignment would require a base pointer. This bug was breaking oggenc on armv6. No test case, an upcoming patch will use this functionality to realign the stack for spill slots when possible. llvm-svn: 147578
* Revert r146997, "Heed spill slot alignment on ARM."Jakob Stoklund Olesen2012-01-031-1/+1
| | | | | | | | | This patch caused a miscompilation of oggenc because a frame pointer was suddenly needed halfway through register allocation. <rdar://problem/10625436> llvm-svn: 147487
* Heed spill slot alignment on ARM.Jakob Stoklund Olesen2011-12-201-1/+1
| | | | | | | | | | | Use the spill slot alignment as well as the local variable alignment to determine when the stack needs to be realigned. This works now that the ARM target can always realign the stack by using a base pointer. Still respect the ARMBaseRegisterInfo::canRealignStack() function vetoing a realigned stack. Don't use aligned spill code in that case. llvm-svn: 146997
* ARM target code clean up. Check for iOS, not Darwin where it makes sense.Evan Cheng2011-12-201-3/+3
| | | | llvm-svn: 146981
* Emit a getMatchingSuperRegClass() implementation for every target.Jakob Stoklund Olesen2011-12-191-98/+0
| | | | | | | | | Use information computed while inferring new register classes to emit accurate, table-driven implementations of getMatchingSuperRegClass(). Delete the old manual, error-prone implementations in the targets. llvm-svn: 146873
* Move global variables in TargetMachine into new TargetOptions class. As an APINick Lewycky2011-12-021-2/+2
| | | | | | | | | | | | 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
* Revert 142337. Thumb1 still doesn't support dynamic stack realignment. :(Chad Rosier2011-10-201-2/+5
| | | | llvm-svn: 142557
* Add support for dynamic stack realignment when in thumb1 mode.Chad Rosier2011-10-181-5/+2
| | | | | | rdar://10288916 llvm-svn: 142337
* Revert r141529. This is causing failures in the test-suite, like bigstack ↵Bill Wendling2011-10-111-11/+2
| | | | | | and ReedSolomon. Boo... llvm-svn: 141716
* When getting the number of bits necessary for addressing modeBill Wendling2011-10-101-2/+11
| | | | | | | | ARMII::AddrModeT1_s, we need to take into account that if the frame register is ARM::SP, then the number of bits is 8. If it's not ARM::SP, then the number of bits is 5. llvm-svn: 141529
* Revert r140924 "Attempt to fix dynamic stack realignment for thumb1 functions."Chad Rosier2011-10-011-2/+5
| | | | | | to appease nightly testers. Not quite there yet. llvm-svn: 140953
* Attempt to fix dynamic stack realignment for thumb1 functions. It is in fact Chad Rosier2011-10-011-5/+2
| | | | | | | | useful if an optimization assumes the stack has been realigned. Credit to Eli for his assistance. rdar://10043857 llvm-svn: 140924
* Store sub-class lists as a bit vector.Jakob Stoklund Olesen2011-09-301-1/+1
| | | | | | | | | | | | | | This uses less memory and it reduces the complexity of sub-class operations: - hasSubClassEq() and friends become O(1) instead of O(N). - getCommonSubClass() becomes O(N) instead of O(N^2). In the future, TableGen will infer register classes. This makes it cheap to add them. llvm-svn: 140898
* Tidy up a bit.Jim Grosbach2011-09-131-152/+78
| | | | llvm-svn: 139635
* Change ARM / Thumb2 addc / adde and subc / sube modeling to use physicalEvan Cheng2011-08-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | register dependency (rather than glue them together). This is general goodness as it gives scheduler more freedom. However it is motivated by a nasty bug in isel. When a i64 sub is expanded to subc + sube. libcall #1 \ \ subc \ / \ \ / \ \ / libcall #2 sube If the libcalls are not serialized (i.e. both have chains which are dag entry), legalizer can serialize them in arbitrary orders. If it's unlucky, it can force libcall #2 before libcall #1 in the above case. subc | libcall #2 | libcall #1 | sube However since subc and sube are "glued" together, this ends up being a cycle when the scheduler combine subc and sube as a single scheduling unit. The right solution is to fix LegalizeType too chains the libcalls together. However, LegalizeType is not processing nodes in order so that's harder than it should be. For now, the move to physical register dependency will do. rdar://10019576 llvm-svn: 138791
* Thumb1 ADD/SUB SP instructions are predicable in Thumb2 mode.Jim Grosbach2011-08-241-3/+3
| | | | | | | | | 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
* Silence a bunch (but not all) "variable written but not read" warningsDuncan Sands2011-08-121-0/+1
| | | | | | 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
* 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
* Migrate LLVM and Clang to use the new makeArrayRef(...) functions where ↵Frits van Bommel2011-07-181-12/+12
| | | | | | | | previously explicit non-default constructors were used. Mostly mechanical with some manual reformatting. llvm-svn: 135390
* 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
* Remove redundant Thumb2 ADD/SUB SP instruction definitions.Jim Grosbach2011-06-291-4/+0
| | | | | | | | | | Unlike Thumb1, Thumb2 does not have dedicated encodings for adjusting the stack pointer. It can just use the normal add-register-immediate encoding since it can use all registers as a source, not just R0-R7. The extra instruction definitions are just duplicates of the normal instructions with the (not well enforced) constraint that the source register was SP. llvm-svn: 134114
* 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
* - Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo andEvan Cheng2011-06-281-5/+5
| | | | | | | | 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
* More refactoring. Move getRegClass from TargetOperandInfo to TargetInstrInfo.Evan Cheng2011-06-271-1/+1
| | | | llvm-svn: 133944
* Merge XXXGenRegisterDesc.inc XXXGenRegisterNames.inc XXXGenRegisterInfo.h.incEvan Cheng2011-06-271-1/+3
| | | | | | into XXXGenRegisterInfo.inc. llvm-svn: 133922
* Starting to refactor Target to separate out code that's needed to fully describeEvan Cheng2011-06-241-3/+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
OpenPOWER on IntegriCloud