maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Target/ARM/ARMBaseInstrInfo.h

420 lines
18 KiB
C
Raw Normal View History

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
2012-02-18 20:03:15 +08:00
//===-- ARMBaseInstrInfo.h - ARM Base Instruction Information ---*- C++ -*-===//
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file contains the Base ARM implementation of the TargetInstrInfo class.
//
//===----------------------------------------------------------------------===//
#ifndef ARMBASEINSTRUCTIONINFO_H
#define ARMBASEINSTRUCTIONINFO_H
#include "ARM.h"
Making use of VFP / NEON floating point multiply-accumulate / subtraction is 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
2010-12-06 06:04:16 +08:00
#include "llvm/ADT/DenseMap.h"
#include "llvm/ADT/SmallSet.h"
Sort includes for all of the .h files under the 'lib' tree. These were missed in the first pass because the script didn't yet handle include guards. Note that the script is now able to handle all of these headers without manual edits. =] llvm-svn: 169224
2012-12-04 15:12:27 +08:00
#include "llvm/CodeGen/MachineInstrBuilder.h"
#include "llvm/Target/TargetInstrInfo.h"
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
Hide the call to InitMCInstrInfo into tblgen generated ctor. llvm-svn: 134244
2011-07-02 01:57:27 +08:00
#define GET_INSTRINFO_HEADER
#include "ARMGenInstrInfo.inc"
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
namespace llvm {
prune #includes a little. llvm-svn: 108929
2010-07-21 05:17:29 +08:00
class ARMSubtarget;
class ARMBaseRegisterInfo;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
Hide the call to InitMCInstrInfo into tblgen generated ctor. llvm-svn: 134244
2011-07-02 01:57:27 +08:00
class ARMBaseInstrInfo : public ARMGenInstrInfo {
prune #includes a little. llvm-svn: 108929
2010-07-21 05:17:29 +08:00
const ARMSubtarget &Subtarget;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is 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
2010-12-06 06:04:16 +08:00
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
protected:
// Can be only subclassed.
Use NEON reg-reg moves, where profitable. This reduces "domain-cross" stalls, when we used to mix vfp and neon code (the former were used for reg-reg moves) llvm-svn: 85764
2009-11-02 08:10:38 +08:00
explicit ARMBaseInstrInfo(const ARMSubtarget &STI);
Making use of VFP / NEON floating point multiply-accumulate / subtraction is 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
2010-12-06 06:04:16 +08:00
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
public:
ARM implement TargetInstrInfo::getNoopForMachoTarget() 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
2012-02-29 07:53:30 +08:00
// Return whether the target has an explicit NOP encoding.
bool hasNOP() const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
// Return the non-pre/post incrementing version of 'Opc'. Return 0
// if there is not such an opcode.
virtual unsigned getUnindexedOpcode(unsigned Opc) const =0;
virtual MachineInstr *convertToThreeAddress(MachineFunction::iterator &MFI,
MachineBasicBlock::iterator &MBBI,
LiveVariables *LV) const;
virtual const ARMBaseRegisterInfo &getRegisterInfo() const =0;
Use NEON reg-reg moves, where profitable. This reduces "domain-cross" stalls, when we used to mix vfp and neon code (the former were used for reg-reg moves) llvm-svn: 85764
2009-11-02 08:10:38 +08:00
const ARMSubtarget &getSubtarget() const { return Subtarget; }
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
Making use of VFP / NEON floating point multiply-accumulate / subtraction is 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
2010-12-06 06:04:16 +08:00
ScheduleHazardRecognizer *
Various bits of framework needed for precise machine-level selection DAG scheduling during isel. Most new functionality is currently guarded by -enable-sched-cycles and -enable-sched-hazard. Added InstrItineraryData::IssueWidth field, currently derived from ARM itineraries, but could be initialized differently on other targets. Added ScheduleHazardRecognizer::MaxLookAhead to indicate whether it is active, and if so how many cycles of state it holds. Added SchedulingPriorityQueue::HasReadyFilter to allowing gating entry into the scheduler's available queue. ScoreboardHazardRecognizer now accesses the ScheduleDAG in order to get information about it's SUnits, provides RecedeCycle for bottom-up scheduling, correctly computes scoreboard depth, tracks IssueCount, and considers potential stall cycles when checking for hazards. ScheduleDAGRRList now models machine cycles and hazards (under flags). It tracks MinAvailableCycle, drives the hazard recognizer and priority queue's ready filter, manages a new PendingQueue, properly accounts for stall cycles, etc. llvm-svn: 122541
2010-12-24 13:03:26 +08:00
CreateTargetHazardRecognizer(const TargetMachine *TM,
const ScheduleDAG *DAG) const;
ScheduleHazardRecognizer *
CreateTargetPostRAHazardRecognizer(const InstrItineraryData *II,
const ScheduleDAG *DAG) const;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is 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
2010-12-06 06:04:16 +08:00
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
// Branch analysis.
virtual bool AnalyzeBranch(MachineBasicBlock &MBB, MachineBasicBlock *&TBB,
MachineBasicBlock *&FBB,
SmallVectorImpl<MachineOperand> &Cond,
eliminate the TargetInstrInfo::GetInstSizeInBytes hook. ARM/PPC/MSP430-specific code (which are the only targets that implement the hook) can directly reference their target-specific instrinfo classes. llvm-svn: 109171
2010-07-23 05:27:00 +08:00
bool AllowModify = false) const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
virtual unsigned RemoveBranch(MachineBasicBlock &MBB) const;
virtual unsigned InsertBranch(MachineBasicBlock &MBB, MachineBasicBlock *TBB,
MachineBasicBlock *FBB,
Add a DebugLoc parameter to TargetInstrInfo::InsertBranch(). This addresses a longstanding deficiency noted in many FIXMEs scattered across all the targets. This effectively moves the problem up one level, replacing eleven FIXMEs in the targets with eight FIXMEs in CodeGen, plus one path through FastISel where we actually supply a DebugLoc, fixing Radar 7421831. llvm-svn: 106243
2010-06-18 06:43:56 +08:00
const SmallVectorImpl<MachineOperand> &Cond,
DebugLoc DL) const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
virtual
bool ReverseBranchCondition(SmallVectorImpl<MachineOperand> &Cond) const;
// Predication support.
- Add MachineInstrBundle.h and MachineInstrBundle.cpp. This includes a function to finalize MI bundles (i.e. add BUNDLE instruction and computing register def and use lists of the BUNDLE instruction) and a pass to unpack bundles. - Teach more of MachineBasic and MachineInstr methods to be bundle aware. - Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to prevent IT blocks from being broken apart. llvm-svn: 146542
2011-12-14 10:11:42 +08:00
bool isPredicated(const MachineInstr *MI) const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
ARMCC::CondCodes getPredicate(const MachineInstr *MI) const {
int PIdx = MI->findFirstPredOperandIdx();
return PIdx != -1 ? (ARMCC::CondCodes)MI->getOperand(PIdx).getImm()
: ARMCC::AL;
}
virtual
bool PredicateInstruction(MachineInstr *MI,
const SmallVectorImpl<MachineOperand> &Pred) const;
virtual
bool SubsumesPredicate(const SmallVectorImpl<MachineOperand> &Pred1,
const SmallVectorImpl<MachineOperand> &Pred2) const;
virtual bool DefinesPredicate(MachineInstr *MI,
std::vector<MachineOperand> &Pred) const;
Add predicate operand to NEON instructions. Fix lots (but not all) 80 col violations in ARMInstrNEON.td. llvm-svn: 89542
2009-11-21 14:21:52 +08:00
virtual bool isPredicable(MachineInstr *MI) const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
/// GetInstSize - Returns the size of the specified MachineInstr.
///
virtual unsigned GetInstSizeInBytes(const MachineInstr* MI) const;
virtual unsigned isLoadFromStackSlot(const MachineInstr *MI,
int &FrameIndex) const;
virtual unsigned isStoreToStackSlot(const MachineInstr *MI,
int &FrameIndex) const;
Implement isLoadFromStackSlotPostFE and isStoreToStackSlotPostFE for ARM. They improve the verbose assembly. llvm-svn: 137069
2011-08-09 05:45:32 +08:00
virtual unsigned isLoadFromStackSlotPostFE(const MachineInstr *MI,
int &FrameIndex) const;
virtual unsigned isStoreToStackSlotPostFE(const MachineInstr *MI,
int &FrameIndex) const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
Replace copyRegToReg with copyPhysReg for ARM. llvm-svn: 108078
2010-07-11 14:33:54 +08:00
virtual void copyPhysReg(MachineBasicBlock &MBB,
MachineBasicBlock::iterator I, DebugLoc DL,
unsigned DestReg, unsigned SrcReg,
bool KillSrc) const;
Use t2LDRi12 and t2STRi12 to load / store to / from stack frames. Eliminate more getOpcode calls. llvm-svn: 77181
2009-07-27 11:14:20 +08:00
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
virtual void storeRegToStackSlot(MachineBasicBlock &MBB,
MachineBasicBlock::iterator MBBI,
unsigned SrcReg, bool isKill, int FrameIndex,
Add argument TargetRegisterInfo to loadRegFromStackSlot and storeRegToStackSlot. llvm-svn: 103193
2010-05-07 03:06:44 +08:00
const TargetRegisterClass *RC,
const TargetRegisterInfo *TRI) const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
virtual void loadRegFromStackSlot(MachineBasicBlock &MBB,
MachineBasicBlock::iterator MBBI,
unsigned DestReg, int FrameIndex,
Add argument TargetRegisterInfo to loadRegFromStackSlot and storeRegToStackSlot. llvm-svn: 103193
2010-05-07 03:06:44 +08:00
const TargetRegisterClass *RC,
const TargetRegisterInfo *TRI) const;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
Move -widen-vmovs to ARMBaseInstrInfo::expandPostRAPseudo(). The VMOVS widening needs to look at the implicit COPY operands. Trying to dig out the COPY instruction from an iterator in copyPhysReg() is the wrong approach. The expandPostRAPseudo() hook gets to look at COPY instructions before they are converted to copyPhysReg() calls. llvm-svn: 141619
2011-10-11 08:59:06 +08:00
virtual bool expandPostRAPseudo(MachineBasicBlock::iterator MI) const;
Add ARM specific emitFrameIndexDebugValue. llvm-svn: 102324
2010-04-26 15:39:25 +08:00
virtual MachineInstr *emitFrameIndexDebugValue(MachineFunction &MF,
Frame index can be negative. llvm-svn: 102577
2010-04-29 09:13:30 +08:00
int FrameIx,
Add ARM specific emitFrameIndexDebugValue. llvm-svn: 102324
2010-04-26 15:39:25 +08:00
uint64_t Offset,
const MDNode *MDPtr,
DebugLoc DL) const;
Refactor code. llvm-svn: 86423
2009-11-08 08:15:23 +08:00
virtual void reMaterialize(MachineBasicBlock &MBB,
MachineBasicBlock::iterator MI,
unsigned DestReg, unsigned SubIdx,
- Change TargetInstrInfo::reMaterialize to pass in TargetRegisterInfo. - If destination is a physical register and it has a subreg index, use the sub-register instead. This fixes PR5423. llvm-svn: 88745
2009-11-14 10:55:43 +08:00
const MachineInstr *Orig,
Slightly change the meaning of the reMaterialize target hook when the original instruction defines subregisters. Any existing subreg indices on the original instruction are preserved or composed with the new subreg index. Also substitute multiple operands mentioning the original register by using the new MachineInstr::substituteRegister() function. This is necessary because there will soon be <imp-def> operands added to non read-modify-write partial definitions. This instruction: %reg1234:foo = FLAP %reg1234<imp-def> will reMaterialize(%reg3333, bar) like this: %reg3333:bar-foo = FLAP %reg333:bar<imp-def> Finally, replace the TargetRegisterInfo pointer argument with a reference to indicate that it cannot be NULL. llvm-svn: 105358
2010-06-03 06:47:25 +08:00
const TargetRegisterInfo &TRI) const;
Refactor code. llvm-svn: 86423
2009-11-08 08:15:23 +08:00
Add Target hook to duplicate machine instructions. Some instructions refer to unique labels, and so cannot be trivially cloned with CloneMachineInstr. llvm-svn: 92873
2010-01-07 07:47:07 +08:00
MachineInstr *duplicate(MachineInstr *Orig, MachineFunction &MF) const;
Implement ARMBaseInstrInfo::commuteInstruction() for MOVCCr. A MOVCCr instruction can be commuted by inverting the condition. This can help reduce register pressure and remove unnecessary copies in some cases. <rdar://problem/11182914> llvm-svn: 154033
2012-04-05 02:23:42 +08:00
MachineInstr *commuteInstruction(MachineInstr*, bool=false) const;
- Change MachineInstr::isIdenticalTo to take a new option that determines whether it should skip checking defs or at least virtual register defs. This subsumes part of the TargetInstrInfo::isIdentical functionality. - Eliminate TargetInstrInfo::isIdentical and replace it with produceSameValue. In the default case, produceSameValue just checks whether two machine instructions are identical (except for virtual register defs). But targets may override it to check for unusual cases (e.g. ARM pic loads from constant pools). llvm-svn: 97628
2010-03-03 09:44:33 +08:00
virtual bool produceSameValue(const MachineInstr *MI0,
Sorry, several patches in one. TargetInstrInfo: Change produceSameValue() to take MachineRegisterInfo as an optional argument. When in SSA form, targets can use it to make more aggressive equality analysis. Machine LICM: 1. Eliminate isLoadFromConstantMemory, use MI.isInvariantLoad instead. 2. Fix a bug which prevent CSE of instructions which are not re-materializable. 3. Use improved form of produceSameValue. ARM: 1. Teach ARM produceSameValue to look pass some PIC labels. 2. Look for operands from different loads of different constant pool entries which have same values. 3. Re-implement PIC GA materialization using movw + movt. Combine the pair with a "add pc" or "ldr [pc]" to form pseudo instructions. This makes it possible to re-materialize the instruction, allow machine LICM to hoist the set of instructions out of the loop and make it possible to CSE them. It's a bit hacky, but it significantly improve code quality. 4. Some minor bug fixes as well. With the fixes, using movw + movt to materialize GAs significantly outperform the load from constantpool method. 186.crafty and 255.vortex improved > 20%, 254.gap and 176.gcc ~10%. llvm-svn: 123905
2011-01-20 16:34:58 +08:00
const MachineInstr *MI1,
const MachineRegisterInfo *MRI) const;
Allow ARM if-converter to be run after post allocation scheduling. - This fixed a number of bugs in if-converter, tail merging, and post-allocation scheduler. If-converter now runs branch folding / tail merging first to maximize if-conversion opportunities. - Also changed the t2IT instruction slightly. It now defines the ITSTATE register which is read by instructions in the IT block. - Added Thumb2 specific hazard recognizer to ensure the scheduler doesn't change the instruction ordering in the IT block (since IT mask has been finalized). It also ensures no other instructions can be scheduled between instructions in the IT block. This is not yet enabled. llvm-svn: 106344
2010-06-19 07:09:54 +08:00
We are missing opportunites to use ldm. Take code like this: void t(int *cp0, int *cp1, int *dp, int fmd) { int c0, c1, d0, d1, d2, d3; c0 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000); c1 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000); /* ... */ } It code gens into something pretty bad. But with this change (analogous to the X86 back-end), it will use ldm and generate few instructions. llvm-svn: 106693
2010-06-24 07:00:16 +08:00
/// areLoadsFromSameBasePtr - This is used by the pre-regalloc scheduler to
/// determine if two loads are loading from the same base address. It should
/// only return true if the base pointers are the same and the only
/// differences between the two addresses is the offset. It also returns the
/// offsets by reference.
virtual bool areLoadsFromSameBasePtr(SDNode *Load1, SDNode *Load2,
int64_t &Offset1, int64_t &Offset2)const;
/// shouldScheduleLoadsNear - This is a used by the pre-regalloc scheduler to
Clean up a few 80 column violations. llvm-svn: 132946
2011-06-14 06:54:22 +08:00
/// determine (in conjunction with areLoadsFromSameBasePtr) if two loads
/// should be scheduled togther. On some targets if two loads are loading from
We are missing opportunites to use ldm. Take code like this: void t(int *cp0, int *cp1, int *dp, int fmd) { int c0, c1, d0, d1, d2, d3; c0 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000); c1 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000); /* ... */ } It code gens into something pretty bad. But with this change (analogous to the X86 back-end), it will use ldm and generate few instructions. llvm-svn: 106693
2010-06-24 07:00:16 +08:00
/// addresses in the same cache line, it's better if they are scheduled
/// together. This function takes two integers that represent the load offsets
/// from the common base address. It returns true if it decides it's desirable
/// to schedule the two loads together. "NumLoads" is the number of loads that
/// have already been scheduled after Load1.
virtual bool shouldScheduleLoadsNear(SDNode *Load1, SDNode *Load2,
int64_t Offset1, int64_t Offset2,
unsigned NumLoads) const;
Allow ARM if-converter to be run after post allocation scheduling. - This fixed a number of bugs in if-converter, tail merging, and post-allocation scheduler. If-converter now runs branch folding / tail merging first to maximize if-conversion opportunities. - Also changed the t2IT instruction slightly. It now defines the ITSTATE register which is read by instructions in the IT block. - Added Thumb2 specific hazard recognizer to ensure the scheduler doesn't change the instruction ordering in the IT block (since IT mask has been finalized). It also ensures no other instructions can be scheduled between instructions in the IT block. This is not yet enabled. llvm-svn: 106344
2010-06-19 07:09:54 +08:00
virtual bool isSchedulingBoundary(const MachineInstr *MI,
const MachineBasicBlock *MBB,
const MachineFunction &MF) const;
Change if-conversion block size limit checks to add some flexibility. llvm-svn: 106901
2010-06-26 06:42:03 +08:00
virtual bool isProfitableToIfCvt(MachineBasicBlock &MBB,
Fix a typo. llvm-svn: 129429
2011-04-13 14:39:16 +08:00
unsigned NumCycles, unsigned ExtraPredCycles,
Use BranchProbability instead of floating points in IfConverter. llvm-svn: 134858
2011-07-10 10:58:07 +08:00
const BranchProbability &Probability) const;
Change if-conversion block size limit checks to add some flexibility. llvm-svn: 106901
2010-06-26 06:42:03 +08:00
Two sets of changes. Sorry they are intermingled. 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
2010-11-03 08:45:17 +08:00
virtual bool isProfitableToIfCvt(MachineBasicBlock &TMBB,
unsigned NumT, unsigned ExtraT,
MachineBasicBlock &FMBB,
unsigned NumF, unsigned ExtraF,
Use BranchProbability instead of floating points in IfConverter. llvm-svn: 134858
2011-07-10 10:58:07 +08:00
const BranchProbability &Probability) const;
Change if-conversion block size limit checks to add some flexibility. llvm-svn: 106901
2010-06-26 06:42:03 +08:00
virtual bool isProfitableToDupForIfCvt(MachineBasicBlock &MBB,
Fix a typo. llvm-svn: 129429
2011-04-13 14:39:16 +08:00
unsigned NumCycles,
Use BranchProbability instead of floating points in IfConverter. llvm-svn: 134858
2011-07-10 10:58:07 +08:00
const BranchProbability
Whitespace. llvm-svn: 164898
2012-09-30 05:27:31 +08:00
&Probability) const {
Fix a typo. llvm-svn: 129429
2011-04-13 14:39:16 +08:00
return NumCycles == 1;
Change if-conversion block size limit checks to add some flexibility. llvm-svn: 106901
2010-06-26 06:42:03 +08:00
}
Add the Optimize Compares pass (disabled by default). This pass tries to remove comparison instructions when possible. For instance, if you have this code: sub r1, 1 cmp r1, 0 bz L1 and "sub" either sets the same flag as the "cmp" instruction or could be converted to set the same flag, then we can eliminate the "cmp" instruction all together. This is a important for ARM where the ALU instructions could set the CPSR flag, but need a special suffix ('s') to do so. llvm-svn: 110423
2010-08-06 09:32:48 +08:00
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
virtual bool isProfitableToUnpredicate(MachineBasicBlock &TMBB,
MachineBasicBlock &FMBB) const;
Add SrcReg2 to analyzeCompare and optimizeCompareInstr to handle Compare instructions with two register operands. llvm-svn: 159465
2012-06-30 05:33:59 +08:00
/// analyzeCompare - For a comparison instruction, return the source registers
/// in SrcReg and SrcReg2 if having two register operands, and the value it
/// compares against in CmpValue. Return true if the comparison instruction
/// can be analyzed.
virtual bool analyzeCompare(const MachineInstr *MI, unsigned &SrcReg,
unsigned &SrcReg2, int &CmpMask,
int &CmpValue) const;
/// optimizeCompareInstr - Convert the instruction to set the zero flag so
/// that we can remove a "comparison with zero"; Remove a redundant CMP
/// instruction if the flags can be updated in the same way by an earlier
/// instruction such as SUB.
virtual bool optimizeCompareInstr(MachineInstr *CmpInstr, unsigned SrcReg,
unsigned SrcReg2, int CmpMask, int CmpValue,
Code clean up. The peephole pass should be the one updating the instruction iterator, not TII->OptimizeCompareInstr. llvm-svn: 119186
2010-11-16 05:20:45 +08:00
const MachineRegisterInfo *MRI) const;
For each instruction itinerary class, specify the number of micro-ops each instruction in the class would be decoded to. Or zero if the number of uOPs must be determined dynamically. This will be used to determine the cost-effectiveness of predicating a micro-coded instruction. llvm-svn: 113513
2010-09-10 02:18:55 +08:00
Handle ARM MOVCC optimization in PeepholeOptimizer. Use the target independent select analysis hooks. llvm-svn: 162060
2012-08-17 07:14:20 +08:00
virtual bool analyzeSelect(const MachineInstr *MI,
SmallVectorImpl<MachineOperand> &Cond,
unsigned &TrueOp, unsigned &FalseOp,
bool &Optimizable) const;
virtual MachineInstr *optimizeSelect(MachineInstr *MI, bool) const;
Remove ARM isel hacks that fold large immediates into a pair of add, sub, and, and xor. The 32-bit move immediates can be hoisted out of loops by machine LICM but the isel hacks were preventing them. Instead, let peephole optimization pass recognize registers that are defined by immediates and the ARM target hook will fold the immediates in. Other changes include 1) do not fold and / xor into cmp to isel TST / TEQ instructions if there are multiple uses. This happens when the 'and' is live out, machine sink would have sinked the computation and that ends up pessimizing code. The peephole pass would recognize situations where the 'and' can be toggled to define CPSR and eliminate the comparison anyway. 2) Move peephole pass to after machine LICM, sink, and CSE to avoid blocking important optimizations. rdar://8663787, rdar://8241368 llvm-svn: 119548
2010-11-18 04:13:28 +08:00
/// FoldImmediate - 'Reg' is known to be defined by a move immediate
/// instruction, try to fold the immediate into the use instruction.
virtual bool FoldImmediate(MachineInstr *UseMI, MachineInstr *DefMI,
unsigned Reg, MachineRegisterInfo *MRI) const;
Two sets of changes. Sorry they are intermingled. 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
2010-11-03 08:45:17 +08:00
virtual unsigned getNumMicroOps(const InstrItineraryData *ItinData,
const MachineInstr *MI) const;
- Add TargetInstrInfo::getOperandLatency() to compute operand latencies. This allow target to correctly compute latency for cases where static scheduling itineraries isn't sufficient. e.g. variable_ops instructions such as ARM::ldm. This also allows target without scheduling itineraries to compute operand latencies. e.g. X86 can return (approximated) latencies for high latency instructions such as division. - Compute operand latencies for those defined by load multiple instructions, e.g. ldm and those used by store multiple instructions, e.g. stm. llvm-svn: 115755
2010-10-06 14:27:31 +08:00
virtual
int getOperandLatency(const InstrItineraryData *ItinData,
const MachineInstr *DefMI, unsigned DefIdx,
const MachineInstr *UseMI, unsigned UseIdx) const;
virtual
int getOperandLatency(const InstrItineraryData *ItinData,
SDNode *DefNode, unsigned DefIdx,
SDNode *UseNode, unsigned UseIdx) const;
Implement TII::get/setExecutionDomain() for ARM. llvm-svn: 140653
2011-09-28 06:57:21 +08:00
/// VFP/NEON execution domains.
std::pair<uint16_t, uint16_t>
getExecutionDomain(const MachineInstr *MI) const;
void setExecutionDomain(MachineInstr *MI, unsigned Domain) const;
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
unsigned getPartialRegUpdateClearance(const MachineInstr*, unsigned,
const TargetRegisterInfo*) const;
void breakPartialRegDependency(MachineBasicBlock::iterator, unsigned,
const TargetRegisterInfo *TRI) const;
Implement getNumLDMAddresses and expose through ARMBaseInstrInfo. llvm-svn: 163922
2012-09-15 02:48:46 +08:00
/// Get the number of addresses by LDM or VLDM or zero for unknown.
unsigned getNumLDMAddresses(const MachineInstr *MI) const;
- Add TargetInstrInfo::getOperandLatency() to compute operand latencies. This allow target to correctly compute latency for cases where static scheduling itineraries isn't sufficient. e.g. variable_ops instructions such as ARM::ldm. This also allows target without scheduling itineraries to compute operand latencies. e.g. X86 can return (approximated) latencies for high latency instructions such as division. - Compute operand latencies for those defined by load multiple instructions, e.g. ldm and those used by store multiple instructions, e.g. stm. llvm-svn: 115755
2010-10-06 14:27:31 +08:00
private:
- Add MachineInstrBundle.h and MachineInstrBundle.cpp. This includes a function to finalize MI bundles (i.e. add BUNDLE instruction and computing register def and use lists of the BUNDLE instruction) and a pass to unpack bundles. - Teach more of MachineBasic and MachineInstr methods to be bundle aware. - Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to prevent IT blocks from being broken apart. llvm-svn: 146542
2011-12-14 10:11:42 +08:00
unsigned getInstBundleLength(const MachineInstr *MI) const;
Code refactoring. llvm-svn: 116002
2010-10-08 07:12:15 +08:00
int getVLDMDefCycle(const InstrItineraryData *ItinData,
- Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo and 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
2011-06-29 03:10:37 +08:00
const MCInstrDesc &DefMCID,
Code refactoring. llvm-svn: 116002
2010-10-08 07:12:15 +08:00
unsigned DefClass,
unsigned DefIdx, unsigned DefAlign) const;
int getLDMDefCycle(const InstrItineraryData *ItinData,
- Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo and 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
2011-06-29 03:10:37 +08:00
const MCInstrDesc &DefMCID,
Code refactoring. llvm-svn: 116002
2010-10-08 07:12:15 +08:00
unsigned DefClass,
unsigned DefIdx, unsigned DefAlign) const;
int getVSTMUseCycle(const InstrItineraryData *ItinData,
- Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo and 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
2011-06-29 03:10:37 +08:00
const MCInstrDesc &UseMCID,
Code refactoring. llvm-svn: 116002
2010-10-08 07:12:15 +08:00
unsigned UseClass,
unsigned UseIdx, unsigned UseAlign) const;
int getSTMUseCycle(const InstrItineraryData *ItinData,
- Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo and 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
2011-06-29 03:10:37 +08:00
const MCInstrDesc &UseMCID,
Code refactoring. llvm-svn: 116002
2010-10-08 07:12:15 +08:00
unsigned UseClass,
unsigned UseIdx, unsigned UseAlign) const;
- Add TargetInstrInfo::getOperandLatency() to compute operand latencies. This allow target to correctly compute latency for cases where static scheduling itineraries isn't sufficient. e.g. variable_ops instructions such as ARM::ldm. This also allows target without scheduling itineraries to compute operand latencies. e.g. X86 can return (approximated) latencies for high latency instructions such as division. - Compute operand latencies for those defined by load multiple instructions, e.g. ldm and those used by store multiple instructions, e.g. stm. llvm-svn: 115755
2010-10-06 14:27:31 +08:00
int getOperandLatency(const InstrItineraryData *ItinData,
- Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo and 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
2011-06-29 03:10:37 +08:00
const MCInstrDesc &DefMCID,
- Add TargetInstrInfo::getOperandLatency() to compute operand latencies. This allow target to correctly compute latency for cases where static scheduling itineraries isn't sufficient. e.g. variable_ops instructions such as ARM::ldm. This also allows target without scheduling itineraries to compute operand latencies. e.g. X86 can return (approximated) latencies for high latency instructions such as division. - Compute operand latencies for those defined by load multiple instructions, e.g. ldm and those used by store multiple instructions, e.g. stm. llvm-svn: 115755
2010-10-06 14:27:31 +08:00
unsigned DefIdx, unsigned DefAlign,
- Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo and 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
2011-06-29 03:10:37 +08:00
const MCInstrDesc &UseMCID,
- Add TargetInstrInfo::getOperandLatency() to compute operand latencies. This allow target to correctly compute latency for cases where static scheduling itineraries isn't sufficient. e.g. variable_ops instructions such as ARM::ldm. This also allows target without scheduling itineraries to compute operand latencies. e.g. X86 can return (approximated) latencies for high latency instructions such as division. - Compute operand latencies for those defined by load multiple instructions, e.g. ldm and those used by store multiple instructions, e.g. stm. llvm-svn: 115755
2010-10-06 14:27:31 +08:00
unsigned UseIdx, unsigned UseAlign) const;
Re-enable register pressure aware machine licm with fixes. Hoist() may have erased the instruction during LICM so UpdateRegPressureAfter() should not reference it afterwards. llvm-svn: 116845
2010-10-20 02:58:51 +08:00
misched: API for minimum vs. expected latency. Minimum latency determines per-cycle scheduling groups. Expected latency determines critical path and cost. llvm-svn: 158021
2012-06-06 05:11:27 +08:00
unsigned getInstrLatency(const InstrItineraryData *ItinData,
const MachineInstr *MI,
unsigned *PredCost = 0) const;
Two sets of changes. Sorry they are intermingled. 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
2010-11-03 08:45:17 +08:00
int getInstrLatency(const InstrItineraryData *ItinData,
SDNode *Node) const;
Re-enable register pressure aware machine licm with fixes. Hoist() may have erased the instruction during LICM so UpdateRegPressureAfter() should not reference it afterwards. llvm-svn: 116845
2010-10-20 02:58:51 +08:00
bool hasHighOperandLatency(const InstrItineraryData *ItinData,
const MachineRegisterInfo *MRI,
const MachineInstr *DefMI, unsigned DefIdx,
const MachineInstr *UseMI, unsigned UseIdx) const;
Use instruction itinerary to determine what instructions are 'cheap'. llvm-svn: 117348
2010-10-26 10:08:50 +08:00
bool hasLowDefLatency(const InstrItineraryData *ItinData,
const MachineInstr *DefMI, unsigned DefIdx) const;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is 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
2010-12-06 06:04:16 +08:00
Lower ARM adds/subs to add/sub after adding optional CPSR operand. This is still a hack until we can teach tblgen to generate the optional CPSR operand rather than an implicit CPSR def. But the strangeness is now limited to the selection DAG. ADD/SUB MI's no longer have implicit CPSR defs, nor do we allow flag setting variants of these opcodes in machine code. There are several corner cases to consider, and getting one wrong would previously lead to nasty miscompilation. It's not the first time I've debugged one, so this time I added enough verification to ensure it won't happen again. llvm-svn: 140228
2011-09-21 10:20:46 +08:00
/// verifyInstruction - Perform target specific instruction verification.
bool verifyInstruction(const MachineInstr *MI, StringRef &ErrInfo) const;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is 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
2010-12-06 06:04:16 +08:00
private:
/// Modeling special VFP / NEON fp MLA / MLS hazards.
/// MLxEntryMap - Map fp MLA / MLS to the corresponding entry in the internal
/// MLx table.
DenseMap<unsigned, unsigned> MLxEntryMap;
/// MLxHazardOpcodes - Set of add / sub and multiply opcodes that would cause
/// stalls when scheduled together with fp MLA / MLS opcodes.
SmallSet<unsigned, 16> MLxHazardOpcodes;
public:
/// isFpMLxInstruction - Return true if the specified opcode is a fp MLA / MLS
/// instruction.
bool isFpMLxInstruction(unsigned Opcode) const {
return MLxEntryMap.count(Opcode);
}
/// isFpMLxInstruction - This version also returns the multiply opcode and the
/// addition / subtraction opcode to expand to. Return true for 'HasLane' for
/// the MLX instructions with an extra lane operand.
bool isFpMLxInstruction(unsigned Opcode, unsigned &MulOpc,
unsigned &AddSubOpc, bool &NegAcc,
bool &HasLane) const;
/// canCauseFpMLxStall - Return true if an instruction of the specified opcode
/// will cause stalls when scheduled after (within 4-cycle window) a fp
/// MLA / MLS instruction.
bool canCauseFpMLxStall(unsigned Opcode) const {
return MLxHazardOpcodes.count(Opcode);
}
ARM scheduler model: Swift has varying latencies, uops for simple ALU ops llvm-svn: 178842
2013-04-05 12:42:00 +08:00
/// Returns true if the instruction has a shift by immediate that can be
/// executed in one cycle less.
bool isSwiftFastImmShift(const MachineInstr *MI) const;
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
};
Get rid of some more getOpcode calls. This also fixes potential problems in ARMBaseInstrInfo routines not recognizing thumb1 instructions when 32-bit and 16-bit instructions mix. llvm-svn: 77218
2009-07-28 02:20:05 +08:00
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
static inline
const MachineInstrBuilder &AddDefaultPred(const MachineInstrBuilder &MIB) {
return MIB.addImm((int64_t)ARMCC::AL).addReg(0);
}
Get rid of some more getOpcode calls. This also fixes potential problems in ARMBaseInstrInfo routines not recognizing thumb1 instructions when 32-bit and 16-bit instructions mix. llvm-svn: 77218
2009-07-28 02:20:05 +08:00
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
static inline
const MachineInstrBuilder &AddDefaultCC(const MachineInstrBuilder &MIB) {
return MIB.addReg(0);
}
Clean up. llvm-svn: 77221
2009-07-28 02:25:24 +08:00
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
static inline
Add support to reduce most of 32-bit Thumb2 arithmetic instructions. llvm-svn: 78550
2009-08-10 10:37:24 +08:00
const MachineInstrBuilder &AddDefaultT1CC(const MachineInstrBuilder &MIB,
bool isDead = false) {
return MIB.addReg(ARM::CPSR, getDefRegState(true) | getDeadRegState(isDead));
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
}
Turn on if-conversion for thumb2. llvm-svn: 79084
2009-08-15 15:59:10 +08:00
static inline
const MachineInstrBuilder &AddNoT1CC(const MachineInstrBuilder &MIB) {
return MIB.addReg(0);
}
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
static inline
bool isUncondBranchOpcode(int Opc) {
return Opc == ARM::B || Opc == ARM::tB || Opc == ARM::t2B;
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
}
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
static inline
bool isCondBranchOpcode(int Opc) {
return Opc == ARM::Bcc || Opc == ARM::tBcc || Opc == ARM::t2Bcc;
}
static inline
bool isJumpTableBranchOpcode(int Opc) {
return Opc == ARM::BR_JTr || Opc == ARM::BR_JTm || Opc == ARM::BR_JTadd ||
Opc == ARM::tBR_JTr || Opc == ARM::t2BR_JT;
}
Add a Thumb BRIND pattern. Change the ARM BRIND assembly to separate the opcode and operand with a tab. Check for these instructions in the usual places. llvm-svn: 85411
2009-10-29 02:26:41 +08:00
static inline
bool isIndirectBranchOpcode(int Opc) {
s/ARM::BRIND/ARM::BX/g to coincide with r120366. llvm-svn: 120371
2010-11-30 08:48:15 +08:00
return Opc == ARM::BX || Opc == ARM::MOVPCRX || Opc == ARM::tBRIND;
Add a Thumb BRIND pattern. Change the ARM BRIND assembly to separate the opcode and operand with a tab. Check for these instructions in the usual places. llvm-svn: 85411
2009-10-29 02:26:41 +08:00
}
Code refactoring. No functionality change. llvm-svn: 78455
2009-08-08 11:20:32 +08:00
/// getInstrPredicate - If instruction is predicated, returns its predicate
/// condition, otherwise returns AL. It also returns the condition code
/// register by reference.
Make ARM and Thumb2 32-bit immediate materialization into a single 32-bit pseudo instruction. This makes it re-materializable. Thumb2 will split it back out into two instructions so IT pass will generate the right mask. Also, this expose opportunies to optimize the movw to a 16-bit move. llvm-svn: 82982
2009-09-28 17:14:39 +08:00
ARMCC::CondCodes getInstrPredicate(const MachineInstr *MI, unsigned &PredReg);
Code refactoring. No functionality change. llvm-svn: 78455
2009-08-08 11:20:32 +08:00
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
int getMatchingCondBranchOpcode(int Opc);
Fold predicable instructions into MOVCC / t2MOVCC. The ARM select instructions are just predicated moves. If the select is the only use of an operand, the instruction defining the operand can be predicated instead, saving one instruction and decreasing register pressure. This implementation can turn AND/ORR/EOR instructions into their corresponding ANDCC/ORRCC/EORCC variants. Ideally, we should be able to predicate any instruction, but we don't yet support predicated instructions in SSA form. llvm-svn: 161994
2012-08-16 06:16:39 +08:00
/// Determine if MI can be folded into an ARM MOVCC instruction, and return the
/// opcode of the SSA instruction representing the conditional MI.
unsigned canFoldARMInstrIntoMOVCC(unsigned Reg,
MachineInstr *&MI,
const MachineRegisterInfo &MRI);
Lower ARM adds/subs to add/sub after adding optional CPSR operand. This is still a hack until we can teach tblgen to generate the optional CPSR operand rather than an implicit CPSR def. But the strangeness is now limited to the selection DAG. ADD/SUB MI's no longer have implicit CPSR defs, nor do we allow flag setting variants of these opcodes in machine code. There are several corner cases to consider, and getting one wrong would previously lead to nasty miscompilation. It's not the first time I've debugged one, so this time I added enough verification to ensure it won't happen again. llvm-svn: 140228
2011-09-21 10:20:46 +08:00
/// Map pseudo instructions that imply an 'S' bit onto real opcodes. Whether
/// the instruction is encoded with an 'S' bit is determined by the optional
/// CPSR def operand.
unsigned convertAddSubFlagsOpcode(unsigned OldOpc);
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
/// emitARMRegPlusImmediate / emitT2RegPlusImmediate - Emits a series of
/// instructions to materializea destreg = basereg + immediate in ARM / Thumb2
/// code.
void emitARMRegPlusImmediate(MachineBasicBlock &MBB,
MachineBasicBlock::iterator &MBBI, DebugLoc dl,
unsigned DestReg, unsigned BaseReg, int NumBytes,
ARMCC::CondCodes Pred, unsigned PredReg,
Preliminary support for ARM frame save directives emission via MI flags. This is just very first approximation how the stuff should be done (e.g. ARM-only for now). More to follow. llvm-svn: 127101
2011-03-06 02:43:32 +08:00
const ARMBaseInstrInfo &TII, unsigned MIFlags = 0);
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
void emitT2RegPlusImmediate(MachineBasicBlock &MBB,
MachineBasicBlock::iterator &MBBI, DebugLoc dl,
unsigned DestReg, unsigned BaseReg, int NumBytes,
ARMCC::CondCodes Pred, unsigned PredReg,
Preliminary support for ARM frame save directives emission via MI flags. This is just very first approximation how the stuff should be done (e.g. ARM-only for now). More to follow. llvm-svn: 127101
2011-03-06 02:43:32 +08:00
const ARMBaseInstrInfo &TII, unsigned MIFlags = 0);
Add a pre-dispatch SjLj EH hook on the unwind edge for targets to do any setup they require. Use this for ARM/Darwin to rematerialize the base pointer from the frame pointer when required. rdar://8564268 llvm-svn: 116879
2010-10-20 07:27:08 +08:00
void emitThumbRegPlusImmediate(MachineBasicBlock &MBB,
Preliminary support for ARM frame save directives emission via MI flags. This is just very first approximation how the stuff should be done (e.g. ARM-only for now). More to follow. llvm-svn: 127101
2011-03-06 02:43:32 +08:00
MachineBasicBlock::iterator &MBBI, DebugLoc dl,
Add a pre-dispatch SjLj EH hook on the unwind edge for targets to do any setup they require. Use this for ARM/Darwin to rematerialize the base pointer from the frame pointer when required. rdar://8564268 llvm-svn: 116879
2010-10-20 07:27:08 +08:00
unsigned DestReg, unsigned BaseReg,
int NumBytes, const TargetInstrInfo &TII,
const ARMBaseRegisterInfo& MRI,
Preliminary support for ARM frame save directives emission via MI flags. This is just very first approximation how the stuff should be done (e.g. ARM-only for now). More to follow. llvm-svn: 127101
2011-03-06 02:43:32 +08:00
unsigned MIFlags = 0);
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
Whitespace cleanup. Remove trailing whitespace. llvm-svn: 78666
2009-08-11 23:33:49 +08:00
/// rewriteARMFrameIndex / rewriteT2FrameIndex -
Fix PR4789. Teach eliminateFrameIndex how to handle VLDRQ and VSTRQ which cannot fold any immediate offset. llvm-svn: 80191
2009-08-27 09:23:50 +08:00
/// Rewrite MI to access 'Offset' bytes from the FP. Return false if the
/// offset could not be handled directly in MI, and return the left-over
/// portion by reference.
bool rewriteARMFrameIndex(MachineInstr &MI, unsigned FrameRegIdx,
unsigned FrameReg, int &Offset,
const ARMBaseInstrInfo &TII);
bool rewriteT2FrameIndex(MachineInstr &MI, unsigned FrameRegIdx,
unsigned FrameReg, int &Offset,
const ARMBaseInstrInfo &TII);
- More refactoring. This gets rid of all of the getOpcode calls. - This change also makes it possible to switch between ARM / Thumb on a per-function basis. - Fixed thumb2 routine which expand reg + arbitrary immediate. It was using using ARM so_imm logic. - Use movw and movt to do reg + imm when profitable. - Other code clean ups and minor optimizations. llvm-svn: 77300
2009-07-28 13:48:47 +08:00
} // End llvm namespace
Checkpoint Thumb2 Instr info work. Generalized base code so that it can be shared between ARM and Thumb2. Not yet activated because register information must be generalized first. llvm-svn: 75010
2009-07-09 00:09:28 +08:00
#endif