summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* CodeGen: TII: Take MachineInstr& in predicate API, NFCDuncan P. N. Exon Smith2016-02-231-6/+6
| | | | | | | | | | | | | Change TargetInstrInfo API to take `MachineInstr&` instead of `MachineInstr*` in the functions related to predicated instructions (I'll try to come back later and get some of the rest). All of these functions require non-null parameters already, so references are more clear. As a bonus, this happens to factor away a host of implicit iterator => pointer conversions. No functionality change intended. llvm-svn: 261605
* PseudoSourceValue: Replace global manager with a manager in a machine function.Alex Lorenz2015-08-111-10/+6
| | | | | | | | | | | | | | | | | | | | | | This commit removes the global manager variable which is responsible for storing and allocating pseudo source values and instead it introduces a new manager class named 'PseudoSourceValueManager'. Machine functions now own an instance of the pseudo source value manager class. This commit also modifies the 'get...' methods in the 'MachinePointerInfo' class to construct pseudo source values using the instance of the pseudo source value manager object from the machine function. This commit updates calls to the 'get...' methods from the 'MachinePointerInfo' class in a lot of different files because those calls now need to pass in a reference to a machine function to those methods. This change will make it easier to serialize pseudo source values as it will enable me to transform the mips specific MipsCallEntry PseudoSourceValue subclass into two target independent subclasses. Reviewers: Akira Hatanaka llvm-svn: 244693
* MC: Modernize MCOperand API naming. NFC.Jim Grosbach2015-05-131-3/+3
| | | | | | MCOperand::Create*() methods renamed to MCOperand::create*(). llvm-svn: 237275
* [ARM] Do not generate invalid encoding for stack adjust, even if this is justQuentin Colombet2015-04-301-2/+7
| | | | | | | | | | | | | temporary. Because of that: 1. The machine verifier was complaining on such code. 2. The generate code worked just because the thumb reduction size pass fixed the opcode. rdar://problem/20749824 llvm-svn: 236247
* Remove the need to cache the subtarget in the ARM TargetRegisterInfoEric Christopher2015-03-121-2/+1
| | | | | | | classes. Replace the frame pointer initialization with a static function that'll look it up via the subtarget on the MachineFunction. llvm-svn: 232010
* Fix handling of negative offsets for AddrModeT2_i8s4 in rewriteT2FrameIndex.Bob Wilson2015-02-241-5/+2
| | | | | | | | | | | | | | This is a follow up to r230233 to fix something that I noticed by inspection. The AddrModeT2_i8s4 addressing mode does not support negative offsets. I spent a good chunk of the day trying to come up with a testcase for this but was not successful. This addressing mode is used to spill and restore GPRPair registers in Thumb2 code and that does not happen often. We also make very limited used of negative offsets when lowering frame indexes. I am going ahead with the change anyway, because I am pretty confident that it is correct. I also added a missing assertion to check that the low bits of the scaled offset are zero. llvm-svn: 230297
* Fix incorrect immediate size for AddrModeT2_i8s4 in rewriteT2FrameIndex.Bob Wilson2015-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The natural way to handle this addressing mode would be to say that it has 8 bits and gets scaled by 4, but since the MC layer is expecting the scaling to be already reflected in the immediate value, we have been setting the Scale to 1. That's fine, but then NumBits needs to be adjusted to reflect the effective increase in the range of the immediate. That adjustment was missing. The consequence is that the register scavenger can fail. The estimateRSStackSizeLimit() function in ARMFrameLowering.cpp correctly assumes that the AddrModeT2_i8s4 address mode can handle scaled offsets up to 1020. Under just the right circumstances, we fail to reserve space for the scavenger because it thinks that nothing will be needed. However, the overly pessimistic behavior in rewriteT2FrameIndex causes some frame indexes to be out of range and require scavenged registers, and so the scavenger asserts. Unfortunately I have not been able to come up with a testcase for this. I can only reproduce it on an internal branch where the frame layout and register allocation is slightly different than trunk. We really need a way to serialize MachineInstr-level IR to write reasonable tests for things like this. rdar://problem/19909005 llvm-svn: 230233
* [ARM] In dynamic-no-pic mode, ARM's post-RA pseudo expansion was incorrectlyAkira Hatanaka2014-08-021-3/+3
| | | | | | | | | expanding pseudo LOAD_STATCK_GUARD using instructions that are normally used in pic mode. This patch fixes the bug. <rdar://problem/17886592> llvm-svn: 214614
* [stack protector] Fix a potential security bug in stack protector where theAkira Hatanaka2014-07-251-0/+9
| | | | | | | | | | | | | | address of the stack guard was being spilled to the stack. Previously the address of the stack guard would get spilled to the stack if it was impossible to keep it in a register. This patch introduces a new target independent node and pseudo instruction which gets expanded post-RA to a sequence of instructions that load the stack guard value. Register allocator can now just remat the value when it can't keep it in a register. <rdar://problem/12475629> llvm-svn: 213967
* Prune includes in ARM target.Craig Topper2014-03-221-1/+0
| | | | llvm-svn: 204548
* ARM: remove unnecessary state-tracking during frame lowering.Tim Northover2013-11-041-0/+7
| | | | | | | | | | | | | | | | | | | | | 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
* Add hint disassembly syntax for 16-bit Thumb hint instructions.Richard Barton2013-10-181-1/+2
| | | | | | Patch by Artyom Skrobov llvm-svn: 192972
* Fix PR 17372: Emitting PLD for stack address for ARM Thumb2Weiming Zhao2013-09-261-0/+7
| | | | | | | t2PLDi12, t2PLDi8, t2PLDs was omitted in Thumb2InstrInfo. This patch fixes it. llvm-svn: 191441
* Reverting 190043 for now.Tilmann Scheller2013-09-051-14/+2
| | | | | | | Solution is not sufficient to prevent 'mov pc, lr' being emitted for jump table code. Test case doesn't trigger the added functionality. llvm-svn: 190047
* ARM: Add GPR register class excluding LR for use with the ADR instruction.Tilmann Scheller2013-09-051-2/+14
| | | | | | | | | This improves code generation for jump tables by avoiding the emission of "mov pc, lr" which could fool the processor into believing this is a return from a function causing mispredicts. The code generation logic for jump tables uses ADR to materialize the address of the jump target. Patch by Daniel Stewart! llvm-svn: 190043
* Don't cache the instruction and register info from the TargetMachine, becauseBill Wendling2013-06-071-1/+1
| | | | | | the internals of TargetMachine could change. llvm-svn: 183488
* Replace Count{Leading,Trailing}Zeros_{32,64} with count{Leading,Trailing}Zeros.Michael J. Spencer2013-05-241-3/+3
| | | | llvm-svn: 182680
* ARM: Use ldrd/strd to spill 64-bit pairs when available.Tim Northover2013-04-211-20/+64
| | | | | | | This allows common sp-offsets to be part of the instruction and is probably faster on modern CPUs too. llvm-svn: 179977
* Remove the explicit MachineInstrBuilder(MI) constructor.Jakob Stoklund Olesen2012-12-191-1/+1
| | | | | | | | | | | | | 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
* Remove all references to TargetInstrInfoImpl.Jakob Stoklund Olesen2012-11-281-2/+2
| | | | | | This class has been merged into its super-class TargetInstrInfo. llvm-svn: 168760
* Remove the TII::scheduleTwoAddrSource() hook.Jakob Stoklund Olesen2012-08-131-42/+0
| | | | | | | | | | | | | | | It never does anything when running 'make check', and it get's in the way of updating live intervals in 2-addr. The hook was originally added to help form IT blocks in Thumb2 code before register allocation, but the pass ordering has changed since then, and we run if-conversion after register allocation now. When the MI scheduler is enabled, there will be no less than two schedulers between 2-addr and Thumb2ITBlockPass, so this hook is unlikely to help anything. llvm-svn: 161794
* Convert more uses of XXXRegisterClass to &XXXRegClass. No functional change ↵Craig Topper2012-04-201-6/+6
| | | | | | since they are equivalent. llvm-svn: 155188
* Prune some includesCraig Topper2012-03-271-1/+0
| | | | llvm-svn: 153502
* Remove unnecessary llvm:: qualificationsCraig Topper2012-03-271-5/+5
| | | | llvm-svn: 153500
* Reorder includes to match coding standards. Fix an issue or two exposed by that.Craig Topper2012-03-171-1/+0
| | | | llvm-svn: 152978
* ARM implement TargetInstrInfo::getNoopForMachoTarget()Jim Grosbach2012-02-281-0/+8
| | | | | | | | | | | | | | Without this hook, functions w/ a completely empty body (including no epilogue) will cause an MCEmitter assertion failure. For example, define internal fastcc void @empty_function() { unreachable } rdar://10947471 llvm-svn: 151673
* 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
* Handle regmask operands in ARMInstrInfo.Jakob Stoklund Olesen2012-02-171-1/+1
| | | | llvm-svn: 150833
* Make use of MachinePointerInfo::getFixedStack. This removes all mentionJay Foad2011-11-151-5/+2
| | | | | | of PseudoSourceValue from lib/Target/. llvm-svn: 144632
* Thumb1 ADD/SUB SP instructions are predicable in Thumb2 mode.Jim Grosbach2011-08-241-3/+2
| | | | | | | | | 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
* Handle new register classes in Thumb2 mode. Should fix the ARM buildbots.Owen Anderson2011-08-111-2/+4
| | | | llvm-svn: 137364
* 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
* Refact ARM Thumb1 tMOVr instruction family.Jim Grosbach2011-06-301-15/+4
| | | | | | | | | | 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-7/+7
| | | | | | | | | 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
* Kill dead code.Jim Grosbach2011-06-301-1/+0
| | | | llvm-svn: 134131
* Remove redundant Thumb2 ADD/SUB SP instruction definitions.Jim Grosbach2011-06-291-6/+4
| | | | | | | | | | 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
* Merge XXXGenRegisterNames.inc into XXXGenRegisterInfo.incEvan Cheng2011-06-281-1/+0
| | | | llvm-svn: 134024
* - Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo andEvan Cheng2011-06-281-1/+1
| | | | | | | | 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
* Preliminary support for ARM frame save directives emission via MI flags.Anton Korobeynikov2011-03-051-8/+11
| | | | | | | This is just very first approximation how the stuff should be done (e.g. ARM-only for now). More to follow. llvm-svn: 127101
* Guard against de-referencing MBB.end().Evan Cheng2011-02-221-1/+4
| | | | llvm-svn: 126192
* Skipping over debugvalue instructions to determine whether the split spot is ↵Evan Cheng2011-02-211-0/+3
| | | | | | in a IT block. rdar://9030770 llvm-svn: 126159
* Making use of VFP / NEON floating point multiply-accumulate / subtraction isEvan Cheng2010-12-051-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
* Two sets of changes. Sorry they are intermingled.Evan Cheng2010-11-031-27/+0
| | | | | | | | | | | | | 1. Fix pre-ra scheduler so it doesn't try to push instructions above calls to "optimize for latency". Call instructions don't have the right latency and this is more likely to use introduce spills. 2. Fix if-converter cost function. For ARM, it should use instruction latencies, not # of micro-ops since multi-latency instructions is completely executed even when the predicate is false. Also, some instruction will be "slower" when they are predicated due to the register def becoming implicit input. rdar://8598427 llvm-svn: 118135
* Thread the determination of branch prediction hit rates back through the ↵Owen Anderson2010-10-011-4/+7
| | | | | | | | | if-conversion heuristic APIs. For now, stick with a constant estimate of 90% (branch predictors are good!), but we might find that we want to provide more nuanced estimates in the future. llvm-svn: 115364
* Provide an option to restore old-style if-conversion heuristics for Thumb2.Owen Anderson2010-10-011-0/+29
| | | | llvm-svn: 115339
* Part one of switching to using a more sane heuristic for determining ↵Owen Anderson2010-09-281-25/+0
| | | | | | | | | | | if-conversion profitability. Rather than having arbitrary cutoffs, actually try to cost model the conversion. For now, the constants are tuned to more or less match our existing behavior, but these will be changed to reflect realistic values as this work proceeds. llvm-svn: 114973
* convert targets to the new MF.getMachineMemOperand interface.Chris Lattner2010-09-211-4/+6
| | | | llvm-svn: 114391
* Teach if-converter to be more careful with predicating instructions that wouldEvan Cheng2010-09-101-1/+1
| | | | | | | | | | | take multiple cycles to decode. For the current if-converter clients (actually only ARM), the instructions that are predicated on false are not nops. They would still take machine cycles to decode. Micro-coded instructions such as LDM / STM can potentially take multiple cycles to decode. If-converter should take treat them as non-micro-coded simple instructions. llvm-svn: 113570
* Many Thumb2 instructions can reference the full ARM register set (i.e.,Jim Grosbach2010-07-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | have 4 bits per register in the operand encoding), but have undefined behavior when the operand value is 13 or 15 (SP and PC, respectively). The trivial coalescer in linear scan sometimes will merge a copy from SP into a subsequent instruction which uses the copy, and if that instruction cannot legally reference SP, we get bad code such as: mls r0,r9,r0,sp instead of: mov r2, sp mls r0, r9, r0, r2 This patch adds a new register class for use by Thumb2 that excludes the problematic registers (SP and PC) and is used instead of GPR for those operands which cannot legally reference PC or SP. The trivial coalescer explicitly requires that the register class of the destination for the COPY instruction contain the source register for the COPY to be considered for coalescing. This prevents errant instructions like that above. PR7499 llvm-svn: 109842
* Replace copyRegToReg with copyPhysReg for ARM.Jakob Stoklund Olesen2010-07-111-27/+19
| | | | llvm-svn: 108078
OpenPOWER on IntegriCloud