2012-02-18 20:03:15 +08:00
|
|
|
//===-- SparcInstrInfo.td - Target Description for Sparc Target -----------===//
|
|
|
|
//
|
2006-02-05 13:50:24 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2012-02-18 20:03:15 +08:00
|
|
|
//
|
2006-02-05 13:50:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file describes the Sparc instructions in TableGen format.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Instruction format superclass
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
include "SparcInstrFormats.td"
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Feature predicates.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-04-02 12:09:06 +08:00
|
|
|
// True when generating 32-bit code.
|
2015-01-31 07:46:43 +08:00
|
|
|
def Is32Bit : Predicate<"!Subtarget->is64Bit()">;
|
2013-04-02 12:09:06 +08:00
|
|
|
|
|
|
|
// True when generating 64-bit code. This also implies HasV9.
|
2015-01-31 07:46:43 +08:00
|
|
|
def Is64Bit : Predicate<"Subtarget->is64Bit()">;
|
2013-04-02 12:09:06 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// HasV9 - This predicate is true when the target processor supports V9
|
|
|
|
// instructions. Note that the machine may be running in 32-bit mode.
|
2015-01-31 07:46:43 +08:00
|
|
|
def HasV9 : Predicate<"Subtarget->isV9()">,
|
2014-03-02 02:54:52 +08:00
|
|
|
AssemblerPredicate<"FeatureV9">;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// HasNoV9 - This predicate is true when the target doesn't have V9
|
|
|
|
// instructions. Use of this is just a hack for the isel not having proper
|
|
|
|
// costs for V8 instructions that are more expensive than their V9 ones.
|
2015-01-31 07:46:43 +08:00
|
|
|
def HasNoV9 : Predicate<"!Subtarget->isV9()">;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// HasVIS - This is true when the target processor has VIS extensions.
|
2015-01-31 07:46:43 +08:00
|
|
|
def HasVIS : Predicate<"Subtarget->isVIS()">,
|
2014-03-03 03:31:21 +08:00
|
|
|
AssemblerPredicate<"FeatureVIS">;
|
2015-01-31 07:46:43 +08:00
|
|
|
def HasVIS2 : Predicate<"Subtarget->isVIS2()">,
|
2014-03-03 03:31:21 +08:00
|
|
|
AssemblerPredicate<"FeatureVIS2">;
|
2015-01-31 07:46:43 +08:00
|
|
|
def HasVIS3 : Predicate<"Subtarget->isVIS3()">,
|
2014-03-03 03:31:21 +08:00
|
|
|
AssemblerPredicate<"FeatureVIS3">;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2013-08-26 02:30:06 +08:00
|
|
|
// HasHardQuad - This is true when the target processor supports quad floating
|
|
|
|
// point instructions.
|
2015-01-31 07:46:43 +08:00
|
|
|
def HasHardQuad : Predicate<"Subtarget->hasHardQuad()">;
|
2013-08-26 02:30:06 +08:00
|
|
|
|
2016-05-16 19:02:00 +08:00
|
|
|
// HasLeonCASA - This is true when the target processor supports the CASA
|
|
|
|
// instruction
|
|
|
|
def HasLeonCASA : Predicate<"Subtarget->hasLeonCasa()">;
|
|
|
|
|
2016-05-09 19:55:15 +08:00
|
|
|
// HasUMAC_SMAC - This is true when the target processor supports the
|
|
|
|
// UMAC and SMAC instructions
|
|
|
|
def HasUMAC_SMAC : Predicate<"Subtarget->hasUmacSmac()">;
|
|
|
|
|
2016-06-19 19:03:28 +08:00
|
|
|
def HasNoFdivSqrtFix : Predicate<"!Subtarget->fixAllFDIVSQRT()">;
|
|
|
|
def HasNoFmulsFix : Predicate<"!Subtarget->replaceFMULS()">;
|
|
|
|
def HasNoFsmuldFix : Predicate<"!Subtarget->fixFSMULD()">;
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// UseDeprecatedInsts - This predicate is true when the target processor is a
|
|
|
|
// V8, or when it is V9 but the V8 deprecated instructions are efficient enough
|
|
|
|
// to use when appropriate. In either of these cases, the instruction selector
|
|
|
|
// will pick deprecated instructions.
|
2015-01-31 07:46:43 +08:00
|
|
|
def UseDeprecatedInsts : Predicate<"Subtarget->useDeprecatedV8Instructions()">;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Instruction Pattern Stuff
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2010-08-18 02:17:12 +08:00
|
|
|
def simm11 : PatLeaf<(imm), [{ return isInt<11>(N->getSExtValue()); }]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2010-08-18 02:17:12 +08:00
|
|
|
def simm13 : PatLeaf<(imm), [{ return isInt<13>(N->getSExtValue()); }]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
def LO10 : SDNodeXForm<imm, [{
|
2015-04-28 22:05:47 +08:00
|
|
|
return CurDAG->getTargetConstant((unsigned)N->getZExtValue() & 1023, SDLoc(N),
|
2009-08-12 04:47:22 +08:00
|
|
|
MVT::i32);
|
2006-02-05 13:50:24 +08:00
|
|
|
}]>;
|
|
|
|
|
|
|
|
def HI22 : SDNodeXForm<imm, [{
|
|
|
|
// Transformation function: shift the immediate value down into the low bits.
|
2015-04-28 22:05:47 +08:00
|
|
|
return CurDAG->getTargetConstant((unsigned)N->getZExtValue() >> 10, SDLoc(N),
|
|
|
|
MVT::i32);
|
2006-02-05 13:50:24 +08:00
|
|
|
}]>;
|
|
|
|
|
|
|
|
def SETHIimm : PatLeaf<(imm), [{
|
2013-04-22 05:18:03 +08:00
|
|
|
return isShiftedUInt<22, 10>(N->getZExtValue());
|
2006-02-05 13:50:24 +08:00
|
|
|
}], HI22>;
|
|
|
|
|
|
|
|
// Addressing modes.
|
2013-04-02 12:08:54 +08:00
|
|
|
def ADDRrr : ComplexPattern<iPTR, 2, "SelectADDRrr", [], []>;
|
|
|
|
def ADDRri : ComplexPattern<iPTR, 2, "SelectADDRri", [frameindex], []>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Address operands
|
2014-01-04 19:30:13 +08:00
|
|
|
def SparcMEMrrAsmOperand : AsmOperandClass {
|
|
|
|
let Name = "MEMrr";
|
2014-01-07 09:49:11 +08:00
|
|
|
let ParserMethod = "parseMEMOperand";
|
2014-01-04 19:30:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
def SparcMEMriAsmOperand : AsmOperandClass {
|
|
|
|
let Name = "MEMri";
|
2014-01-07 09:49:11 +08:00
|
|
|
let ParserMethod = "parseMEMOperand";
|
2014-01-04 19:30:13 +08:00
|
|
|
}
|
|
|
|
|
2013-04-02 12:08:54 +08:00
|
|
|
def MEMrr : Operand<iPTR> {
|
2006-02-05 13:50:24 +08:00
|
|
|
let PrintMethod = "printMemOperand";
|
2013-04-02 12:08:54 +08:00
|
|
|
let MIOperandInfo = (ops ptr_rc, ptr_rc);
|
2014-01-04 19:30:13 +08:00
|
|
|
let ParserMatchClass = SparcMEMrrAsmOperand;
|
2006-02-05 13:50:24 +08:00
|
|
|
}
|
2013-04-02 12:08:54 +08:00
|
|
|
def MEMri : Operand<iPTR> {
|
2006-02-05 13:50:24 +08:00
|
|
|
let PrintMethod = "printMemOperand";
|
2013-04-02 12:08:54 +08:00
|
|
|
let MIOperandInfo = (ops ptr_rc, i32imm);
|
2014-01-04 19:30:13 +08:00
|
|
|
let ParserMatchClass = SparcMEMriAsmOperand;
|
2006-02-05 13:50:24 +08:00
|
|
|
}
|
|
|
|
|
2013-09-22 14:48:52 +08:00
|
|
|
def TLSSym : Operand<iPTR>;
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Branch targets have OtherVT type.
|
2014-01-05 10:13:48 +08:00
|
|
|
def brtarget : Operand<OtherVT> {
|
|
|
|
let EncoderMethod = "getBranchTargetOpValue";
|
|
|
|
}
|
|
|
|
|
2014-03-02 06:03:07 +08:00
|
|
|
def bprtarget : Operand<OtherVT> {
|
|
|
|
let EncoderMethod = "getBranchPredTargetOpValue";
|
|
|
|
}
|
|
|
|
|
2014-03-02 17:46:56 +08:00
|
|
|
def bprtarget16 : Operand<OtherVT> {
|
|
|
|
let EncoderMethod = "getBranchOnRegTargetOpValue";
|
|
|
|
}
|
|
|
|
|
2014-01-05 10:13:48 +08:00
|
|
|
def calltarget : Operand<i32> {
|
|
|
|
let EncoderMethod = "getCallTargetOpValue";
|
2014-03-01 16:30:58 +08:00
|
|
|
let DecoderMethod = "DecodeCall";
|
2014-01-05 10:13:48 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2014-03-01 17:11:57 +08:00
|
|
|
def simm13Op : Operand<i32> {
|
|
|
|
let DecoderMethod = "DecodeSIMM13";
|
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Operand for printing out a condition code.
|
|
|
|
let PrintMethod = "printCCOperand" in
|
|
|
|
def CCOp : Operand<i32>;
|
|
|
|
|
2013-06-07 08:03:36 +08:00
|
|
|
def SDTSPcmpicc :
|
|
|
|
SDTypeProfile<0, 2, [SDTCisInt<0>, SDTCisSameAs<0, 1>]>;
|
2013-06-05 02:33:25 +08:00
|
|
|
def SDTSPcmpfcc :
|
2006-02-10 14:58:25 +08:00
|
|
|
SDTypeProfile<0, 2, [SDTCisFP<0>, SDTCisSameAs<0, 1>]>;
|
2013-06-05 02:33:25 +08:00
|
|
|
def SDTSPbrcc :
|
2006-02-10 14:58:25 +08:00
|
|
|
SDTypeProfile<0, 2, [SDTCisVT<0, OtherVT>, SDTCisVT<1, i32>]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def SDTSPselectcc :
|
2006-02-10 14:58:25 +08:00
|
|
|
SDTypeProfile<1, 3, [SDTCisSameAs<0, 1>, SDTCisSameAs<1, 2>, SDTCisVT<3, i32>]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def SDTSPFTOI :
|
|
|
|
SDTypeProfile<1, 1, [SDTCisVT<0, f32>, SDTCisFP<1>]>;
|
|
|
|
def SDTSPITOF :
|
|
|
|
SDTypeProfile<1, 1, [SDTCisFP<0>, SDTCisVT<1, f32>]>;
|
2013-11-03 20:28:40 +08:00
|
|
|
def SDTSPFTOX :
|
|
|
|
SDTypeProfile<1, 1, [SDTCisVT<0, f64>, SDTCisFP<1>]>;
|
|
|
|
def SDTSPXTOF :
|
|
|
|
SDTypeProfile<1, 1, [SDTCisFP<0>, SDTCisVT<1, f64>]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2013-09-22 14:48:52 +08:00
|
|
|
def SDTSPtlsadd :
|
|
|
|
SDTypeProfile<1, 3, [SDTCisInt<0>, SDTCisSameAs<0, 1>, SDTCisPtrTy<2>]>;
|
|
|
|
def SDTSPtlsld :
|
|
|
|
SDTypeProfile<1, 2, [SDTCisPtrTy<0>, SDTCisPtrTy<1>]>;
|
|
|
|
|
2016-05-04 17:33:30 +08:00
|
|
|
def SDTSPeh_sjlj_setjmp : SDTypeProfile<1, 1, [SDTCisInt<0>, SDTCisPtrTy<1>]>;
|
|
|
|
def SDTSPeh_sjlj_longjmp: SDTypeProfile<0, 1, [SDTCisPtrTy<0>]>;
|
|
|
|
|
2013-06-07 08:03:36 +08:00
|
|
|
def SPcmpicc : SDNode<"SPISD::CMPICC", SDTSPcmpicc, [SDNPOutGlue]>;
|
2010-12-24 02:28:41 +08:00
|
|
|
def SPcmpfcc : SDNode<"SPISD::CMPFCC", SDTSPcmpfcc, [SDNPOutGlue]>;
|
|
|
|
def SPbricc : SDNode<"SPISD::BRICC", SDTSPbrcc, [SDNPHasChain, SDNPInGlue]>;
|
2013-04-03 12:41:44 +08:00
|
|
|
def SPbrxcc : SDNode<"SPISD::BRXCC", SDTSPbrcc, [SDNPHasChain, SDNPInGlue]>;
|
2010-12-24 02:28:41 +08:00
|
|
|
def SPbrfcc : SDNode<"SPISD::BRFCC", SDTSPbrcc, [SDNPHasChain, SDNPInGlue]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
def SPhi : SDNode<"SPISD::Hi", SDTIntUnaryOp>;
|
|
|
|
def SPlo : SDNode<"SPISD::Lo", SDTIntUnaryOp>;
|
|
|
|
|
|
|
|
def SPftoi : SDNode<"SPISD::FTOI", SDTSPFTOI>;
|
|
|
|
def SPitof : SDNode<"SPISD::ITOF", SDTSPITOF>;
|
2013-11-03 20:28:40 +08:00
|
|
|
def SPftox : SDNode<"SPISD::FTOX", SDTSPFTOX>;
|
|
|
|
def SPxtof : SDNode<"SPISD::XTOF", SDTSPXTOF>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2010-12-24 02:28:41 +08:00
|
|
|
def SPselecticc : SDNode<"SPISD::SELECT_ICC", SDTSPselectcc, [SDNPInGlue]>;
|
2013-04-04 11:08:00 +08:00
|
|
|
def SPselectxcc : SDNode<"SPISD::SELECT_XCC", SDTSPselectcc, [SDNPInGlue]>;
|
2010-12-24 02:28:41 +08:00
|
|
|
def SPselectfcc : SDNode<"SPISD::SELECT_FCC", SDTSPselectcc, [SDNPInGlue]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2016-05-04 17:33:30 +08:00
|
|
|
def SPsjlj_setjmp: SDNode<"SPISD::EH_SJLJ_SETJMP",
|
|
|
|
SDTSPeh_sjlj_setjmp,
|
|
|
|
[SDNPHasChain, SDNPSideEffect]>;
|
|
|
|
def SPsjlj_longjmp: SDNode<"SPISD::EH_SJLJ_LONGJMP",
|
|
|
|
SDTSPeh_sjlj_longjmp,
|
|
|
|
[SDNPHasChain, SDNPSideEffect]>;
|
|
|
|
|
2009-08-26 12:50:17 +08:00
|
|
|
// These are target-independent nodes, but have target-specific formats.
|
2007-11-13 17:19:02 +08:00
|
|
|
def SDT_SPCallSeqStart : SDCallSeqStart<[ SDTCisVT<0, i32> ]>;
|
|
|
|
def SDT_SPCallSeqEnd : SDCallSeqEnd<[ SDTCisVT<0, i32>,
|
|
|
|
SDTCisVT<1, i32> ]>;
|
2007-11-13 08:44:25 +08:00
|
|
|
|
2007-11-13 17:19:02 +08:00
|
|
|
def callseq_start : SDNode<"ISD::CALLSEQ_START", SDT_SPCallSeqStart,
|
2010-12-24 02:28:41 +08:00
|
|
|
[SDNPHasChain, SDNPOutGlue]>;
|
2007-11-13 17:19:02 +08:00
|
|
|
def callseq_end : SDNode<"ISD::CALLSEQ_END", SDT_SPCallSeqEnd,
|
2010-12-24 02:28:41 +08:00
|
|
|
[SDNPHasChain, SDNPOptInGlue, SDNPOutGlue]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2011-01-12 11:18:21 +08:00
|
|
|
def SDT_SPCall : SDTypeProfile<0, -1, [SDTCisVT<0, i32>]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def call : SDNode<"SPISD::CALL", SDT_SPCall,
|
2011-01-12 11:18:21 +08:00
|
|
|
[SDNPHasChain, SDNPOptInGlue, SDNPOutGlue,
|
|
|
|
SDNPVariadic]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2011-02-21 11:42:44 +08:00
|
|
|
def SDT_SPRet : SDTypeProfile<0, 1, [SDTCisVT<0, i32>]>;
|
|
|
|
def retflag : SDNode<"SPISD::RET_FLAG", SDT_SPRet,
|
2013-02-06 02:16:58 +08:00
|
|
|
[SDNPHasChain, SDNPOptInGlue, SDNPVariadic]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2011-01-22 06:00:00 +08:00
|
|
|
def flushw : SDNode<"SPISD::FLUSHW", SDTNone,
|
2012-08-24 08:31:13 +08:00
|
|
|
[SDNPHasChain, SDNPSideEffect, SDNPMayStore]>;
|
2011-01-12 13:08:36 +08:00
|
|
|
|
2013-09-22 14:48:52 +08:00
|
|
|
def tlsadd : SDNode<"SPISD::TLS_ADD", SDTSPtlsadd>;
|
|
|
|
def tlsld : SDNode<"SPISD::TLS_LD", SDTSPtlsld>;
|
|
|
|
def tlscall : SDNode<"SPISD::TLS_CALL", SDT_SPCall,
|
|
|
|
[SDNPHasChain, SDNPOptInGlue, SDNPOutGlue,
|
|
|
|
SDNPVariadic]>;
|
|
|
|
|
2014-01-29 11:35:08 +08:00
|
|
|
def getPCX : Operand<iPTR> {
|
2009-09-16 01:46:24 +08:00
|
|
|
let PrintMethod = "printGetPCX";
|
2011-02-21 11:42:44 +08:00
|
|
|
}
|
2009-09-16 01:46:24 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// SPARC Flag Conditions
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
// Note that these values must be kept in sync with the CCOp::CondCode enum
|
|
|
|
// values.
|
|
|
|
class ICC_VAL<int N> : PatLeaf<(i32 N)>;
|
|
|
|
def ICC_NE : ICC_VAL< 9>; // Not Equal
|
|
|
|
def ICC_E : ICC_VAL< 1>; // Equal
|
|
|
|
def ICC_G : ICC_VAL<10>; // Greater
|
|
|
|
def ICC_LE : ICC_VAL< 2>; // Less or Equal
|
|
|
|
def ICC_GE : ICC_VAL<11>; // Greater or Equal
|
|
|
|
def ICC_L : ICC_VAL< 3>; // Less
|
|
|
|
def ICC_GU : ICC_VAL<12>; // Greater Unsigned
|
|
|
|
def ICC_LEU : ICC_VAL< 4>; // Less or Equal Unsigned
|
|
|
|
def ICC_CC : ICC_VAL<13>; // Carry Clear/Great or Equal Unsigned
|
|
|
|
def ICC_CS : ICC_VAL< 5>; // Carry Set/Less Unsigned
|
|
|
|
def ICC_POS : ICC_VAL<14>; // Positive
|
|
|
|
def ICC_NEG : ICC_VAL< 6>; // Negative
|
|
|
|
def ICC_VC : ICC_VAL<15>; // Overflow Clear
|
|
|
|
def ICC_VS : ICC_VAL< 7>; // Overflow Set
|
|
|
|
|
|
|
|
class FCC_VAL<int N> : PatLeaf<(i32 N)>;
|
|
|
|
def FCC_U : FCC_VAL<23>; // Unordered
|
|
|
|
def FCC_G : FCC_VAL<22>; // Greater
|
|
|
|
def FCC_UG : FCC_VAL<21>; // Unordered or Greater
|
|
|
|
def FCC_L : FCC_VAL<20>; // Less
|
|
|
|
def FCC_UL : FCC_VAL<19>; // Unordered or Less
|
|
|
|
def FCC_LG : FCC_VAL<18>; // Less or Greater
|
|
|
|
def FCC_NE : FCC_VAL<17>; // Not Equal
|
|
|
|
def FCC_E : FCC_VAL<25>; // Equal
|
2016-02-27 20:49:59 +08:00
|
|
|
def FCC_UE : FCC_VAL<26>; // Unordered or Equal
|
|
|
|
def FCC_GE : FCC_VAL<27>; // Greater or Equal
|
|
|
|
def FCC_UGE : FCC_VAL<28>; // Unordered or Greater or Equal
|
|
|
|
def FCC_LE : FCC_VAL<29>; // Less or Equal
|
|
|
|
def FCC_ULE : FCC_VAL<30>; // Unordered or Less or Equal
|
|
|
|
def FCC_O : FCC_VAL<31>; // Ordered
|
|
|
|
|
|
|
|
class CPCC_VAL<int N> : PatLeaf<(i32 N)>;
|
|
|
|
def CPCC_3 : CPCC_VAL<39>; // 3
|
|
|
|
def CPCC_2 : CPCC_VAL<38>; // 2
|
|
|
|
def CPCC_23 : CPCC_VAL<37>; // 2 or 3
|
|
|
|
def CPCC_1 : CPCC_VAL<36>; // 1
|
|
|
|
def CPCC_13 : CPCC_VAL<35>; // 1 or 3
|
|
|
|
def CPCC_12 : CPCC_VAL<34>; // 1 or 2
|
|
|
|
def CPCC_123 : CPCC_VAL<33>; // 1 or 2 or 3
|
|
|
|
def CPCC_0 : CPCC_VAL<41>; // 0
|
|
|
|
def CPCC_03 : CPCC_VAL<42>; // 0 or 3
|
|
|
|
def CPCC_02 : CPCC_VAL<43>; // 0 or 2
|
|
|
|
def CPCC_023 : CPCC_VAL<44>; // 0 or 2 or 3
|
|
|
|
def CPCC_01 : CPCC_VAL<45>; // 0 or 1
|
|
|
|
def CPCC_013 : CPCC_VAL<46>; // 0 or 1 or 3
|
|
|
|
def CPCC_012 : CPCC_VAL<47>; // 0 or 1 or 2
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2006-09-02 06:28:02 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Instruction Class Templates
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
/// F3_12 multiclass - Define a normal F3_1/F3_2 pattern in one shot.
|
2013-12-29 15:15:09 +08:00
|
|
|
multiclass F3_12<string OpcStr, bits<6> Op3Val, SDNode OpNode,
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
RegisterClass RC, ValueType Ty, Operand immOp,
|
|
|
|
InstrItinClass itin = IIC_iu_instr> {
|
2013-06-05 02:33:25 +08:00
|
|
|
def rr : F3_1<2, Op3Val,
|
2014-01-06 16:08:58 +08:00
|
|
|
(outs RC:$rd), (ins RC:$rs1, RC:$rs2),
|
|
|
|
!strconcat(OpcStr, " $rs1, $rs2, $rd"),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set Ty:$rd, (OpNode Ty:$rs1, Ty:$rs2))],
|
|
|
|
itin>;
|
2006-09-02 06:28:02 +08:00
|
|
|
def ri : F3_2<2, Op3Val,
|
2014-01-06 16:08:58 +08:00
|
|
|
(outs RC:$rd), (ins RC:$rs1, immOp:$simm13),
|
|
|
|
!strconcat(OpcStr, " $rs1, $simm13, $rd"),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set Ty:$rd, (OpNode Ty:$rs1, (Ty simm13:$simm13)))],
|
|
|
|
itin>;
|
2006-09-02 06:28:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// F3_12np multiclass - Define a normal F3_1/F3_2 pattern in one shot, with no
|
|
|
|
/// pattern.
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
multiclass F3_12np<string OpcStr, bits<6> Op3Val, InstrItinClass itin = IIC_iu_instr> {
|
2013-06-05 02:33:25 +08:00
|
|
|
def rr : F3_1<2, Op3Val,
|
2014-01-06 16:08:58 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
!strconcat(OpcStr, " $rs1, $rs2, $rd"), [],
|
|
|
|
itin>;
|
2006-09-02 06:28:02 +08:00
|
|
|
def ri : F3_2<2, Op3Val,
|
2014-03-01 17:11:57 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
!strconcat(OpcStr, " $rs1, $simm13, $rd"), [],
|
|
|
|
itin>;
|
2006-09-02 06:28:02 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2014-01-10 05:49:18 +08:00
|
|
|
// Load multiclass - Define both Reg+Reg/Reg+Imm patterns in one shot.
|
|
|
|
multiclass Load<string OpcStr, bits<6> Op3Val, SDPatternOperator OpNode,
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
RegisterClass RC, ValueType Ty, InstrItinClass itin = IIC_iu_instr> {
|
2014-01-10 05:49:18 +08:00
|
|
|
def rr : F3_1<3, Op3Val,
|
|
|
|
(outs RC:$dst), (ins MEMrr:$addr),
|
|
|
|
!strconcat(OpcStr, " [$addr], $dst"),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set Ty:$dst, (OpNode ADDRrr:$addr))],
|
|
|
|
itin>;
|
2014-01-10 05:49:18 +08:00
|
|
|
def ri : F3_2<3, Op3Val,
|
|
|
|
(outs RC:$dst), (ins MEMri:$addr),
|
|
|
|
!strconcat(OpcStr, " [$addr], $dst"),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set Ty:$dst, (OpNode ADDRri:$addr))],
|
|
|
|
itin>;
|
2014-01-10 05:49:18 +08:00
|
|
|
}
|
|
|
|
|
2015-08-19 23:59:49 +08:00
|
|
|
// TODO: Instructions of the LoadASI class are currently asm only; hooking up
|
2015-08-19 05:31:46 +08:00
|
|
|
// CodeGen's address spaces to use these is a future task.
|
2015-08-19 23:59:49 +08:00
|
|
|
class LoadASI<string OpcStr, bits<6> Op3Val, SDPatternOperator OpNode,
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
RegisterClass RC, ValueType Ty, InstrItinClass itin = NoItinerary> :
|
2015-08-19 05:31:46 +08:00
|
|
|
F3_1_asi<3, Op3Val, (outs RC:$dst), (ins MEMrr:$addr, i8imm:$asi),
|
|
|
|
!strconcat(OpcStr, "a [$addr] $asi, $dst"),
|
|
|
|
[]>;
|
|
|
|
|
Sparc: Add the "alternate address space" load/store instructions.
- Adds support for the asm syntax, which has an immediate integer
"ASI" (address space identifier) appearing after an address, before
a comma.
- Adds the various-width load, store, and swap in alternate address
space instructions. (ldsba, ldsha, lduba, lduha, lda, stba, stha,
sta, swapa)
This does not attempt to hook these instructions up to pointer address
spaces in LLVM, although that would probably be a reasonable thing to
do in the future.
Differential Revision: http://reviews.llvm.org/D8904
llvm-svn: 237581
2015-05-19 00:35:04 +08:00
|
|
|
// LoadA multiclass - As above, but also define alternate address space variant
|
|
|
|
multiclass LoadA<string OpcStr, bits<6> Op3Val, bits<6> LoadAOp3Val,
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
SDPatternOperator OpNode, RegisterClass RC, ValueType Ty,
|
|
|
|
InstrItinClass itin = NoItinerary> :
|
|
|
|
Load<OpcStr, Op3Val, OpNode, RC, Ty, itin> {
|
2015-08-19 23:59:49 +08:00
|
|
|
def Arr : LoadASI<OpcStr, LoadAOp3Val, OpNode, RC, Ty>;
|
Sparc: Add the "alternate address space" load/store instructions.
- Adds support for the asm syntax, which has an immediate integer
"ASI" (address space identifier) appearing after an address, before
a comma.
- Adds the various-width load, store, and swap in alternate address
space instructions. (ldsba, ldsha, lduba, lduha, lda, stba, stha,
sta, swapa)
This does not attempt to hook these instructions up to pointer address
spaces in LLVM, although that would probably be a reasonable thing to
do in the future.
Differential Revision: http://reviews.llvm.org/D8904
llvm-svn: 237581
2015-05-19 00:35:04 +08:00
|
|
|
}
|
|
|
|
|
2015-08-20 03:30:57 +08:00
|
|
|
// The LDSTUB instruction is supported for asm only.
|
|
|
|
// It is unlikely that general-purpose code could make use of it.
|
|
|
|
// CAS is preferred for sparc v9.
|
|
|
|
def LDSTUBrr : F3_1<3, 0b001101, (outs IntRegs:$dst), (ins MEMrr:$addr),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"ldstub [$addr], $dst", []>;
|
2015-08-20 03:30:57 +08:00
|
|
|
def LDSTUBri : F3_2<3, 0b001101, (outs IntRegs:$dst), (ins MEMri:$addr),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"ldstub [$addr], $dst", []>;
|
2015-08-20 03:30:57 +08:00
|
|
|
def LDSTUBArr : F3_1_asi<3, 0b011101, (outs IntRegs:$dst),
|
|
|
|
(ins MEMrr:$addr, i8imm:$asi),
|
|
|
|
"ldstuba [$addr] $asi, $dst", []>;
|
|
|
|
|
2014-01-10 05:49:18 +08:00
|
|
|
// Store multiclass - Define both Reg+Reg/Reg+Imm patterns in one shot.
|
|
|
|
multiclass Store<string OpcStr, bits<6> Op3Val, SDPatternOperator OpNode,
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
RegisterClass RC, ValueType Ty, InstrItinClass itin = IIC_st> {
|
2014-01-10 05:49:18 +08:00
|
|
|
def rr : F3_1<3, Op3Val,
|
|
|
|
(outs), (ins MEMrr:$addr, RC:$rd),
|
|
|
|
!strconcat(OpcStr, " $rd, [$addr]"),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(OpNode Ty:$rd, ADDRrr:$addr)],
|
|
|
|
itin>;
|
2014-01-10 05:49:18 +08:00
|
|
|
def ri : F3_2<3, Op3Val,
|
|
|
|
(outs), (ins MEMri:$addr, RC:$rd),
|
|
|
|
!strconcat(OpcStr, " $rd, [$addr]"),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(OpNode Ty:$rd, ADDRri:$addr)],
|
|
|
|
itin>;
|
2014-01-10 05:49:18 +08:00
|
|
|
}
|
|
|
|
|
2015-08-19 23:59:49 +08:00
|
|
|
// TODO: Instructions of the StoreASI class are currently asm only; hooking up
|
2015-08-19 05:31:46 +08:00
|
|
|
// CodeGen's address spaces to use these is a future task.
|
2015-08-19 23:59:49 +08:00
|
|
|
class StoreASI<string OpcStr, bits<6> Op3Val,
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
SDPatternOperator OpNode, RegisterClass RC, ValueType Ty,
|
|
|
|
InstrItinClass itin = IIC_st> :
|
2015-08-19 05:31:46 +08:00
|
|
|
F3_1_asi<3, Op3Val, (outs), (ins MEMrr:$addr, RC:$rd, i8imm:$asi),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
!strconcat(OpcStr, "a $rd, [$addr] $asi"),
|
|
|
|
[],
|
|
|
|
itin>;
|
2015-08-19 05:31:46 +08:00
|
|
|
|
|
|
|
multiclass StoreA<string OpcStr, bits<6> Op3Val, bits<6> StoreAOp3Val,
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
SDPatternOperator OpNode, RegisterClass RC, ValueType Ty,
|
|
|
|
InstrItinClass itin = IIC_st> :
|
2015-08-19 05:31:46 +08:00
|
|
|
Store<OpcStr, Op3Val, OpNode, RC, Ty> {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
def Arr : StoreASI<OpcStr, StoreAOp3Val, OpNode, RC, Ty, itin>;
|
Sparc: Add the "alternate address space" load/store instructions.
- Adds support for the asm syntax, which has an immediate integer
"ASI" (address space identifier) appearing after an address, before
a comma.
- Adds the various-width load, store, and swap in alternate address
space instructions. (ldsba, ldsha, lduba, lduha, lda, stba, stha,
sta, swapa)
This does not attempt to hook these instructions up to pointer address
spaces in LLVM, although that would probably be a reasonable thing to
do in the future.
Differential Revision: http://reviews.llvm.org/D8904
llvm-svn: 237581
2015-05-19 00:35:04 +08:00
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Instructions
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
// Pseudo instructions.
|
Change instruction description to split OperandList into OutOperandList and
InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
llvm-svn: 40033
2007-07-19 09:14:50 +08:00
|
|
|
class Pseudo<dag outs, dag ins, string asmstr, list<dag> pattern>
|
2014-01-04 19:30:13 +08:00
|
|
|
: InstSP<outs, ins, asmstr, pattern> {
|
|
|
|
let isCodeGenOnly = 1;
|
|
|
|
let isPseudo = 1;
|
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2009-09-16 01:46:24 +08:00
|
|
|
// GETPCX for PIC
|
2011-01-12 11:52:59 +08:00
|
|
|
let Defs = [O7] in {
|
2009-09-16 01:46:24 +08:00
|
|
|
def GETPCX : Pseudo<(outs getPCX:$getpcseq), (ins), "$getpcseq", [] >;
|
|
|
|
}
|
|
|
|
|
2007-09-12 03:55:27 +08:00
|
|
|
let Defs = [O6], Uses = [O6] in {
|
Change instruction description to split OperandList into OutOperandList and
InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
llvm-svn: 40033
2007-07-19 09:14:50 +08:00
|
|
|
def ADJCALLSTACKDOWN : Pseudo<(outs), (ins i32imm:$amt),
|
2006-02-05 13:50:24 +08:00
|
|
|
"!ADJCALLSTACKDOWN $amt",
|
2008-10-12 06:08:30 +08:00
|
|
|
[(callseq_start timm:$amt)]>;
|
2007-11-13 08:44:25 +08:00
|
|
|
def ADJCALLSTACKUP : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2),
|
|
|
|
"!ADJCALLSTACKUP $amt1",
|
2008-10-12 06:08:30 +08:00
|
|
|
[(callseq_end timm:$amt1, timm:$amt2)]>;
|
2007-09-12 03:55:27 +08:00
|
|
|
}
|
2007-12-13 07:12:09 +08:00
|
|
|
|
2011-01-22 06:00:00 +08:00
|
|
|
let hasSideEffects = 1, mayStore = 1 in {
|
|
|
|
let rd = 0, rs1 = 0, rs2 = 0 in
|
|
|
|
def FLUSHW : F3_1<0b10, 0b101011, (outs), (ins),
|
|
|
|
"flushw",
|
|
|
|
[(flushw)]>, Requires<[HasV9]>;
|
|
|
|
let rd = 0, rs1 = 1, simm13 = 3 in
|
|
|
|
def TA3 : F3_2<0b10, 0b111010, (outs), (ins),
|
|
|
|
"ta 3",
|
|
|
|
[(flushw)]>;
|
|
|
|
}
|
2011-01-12 13:08:36 +08:00
|
|
|
|
2009-10-30 02:10:34 +08:00
|
|
|
// SELECT_CC_* - Used to implement the SELECT_CC DAG operation. Expanded after
|
|
|
|
// instruction selection into a branch sequence. This has to handle all
|
|
|
|
// permutations of selection between i32/f32/f64 on ICC and FCC.
|
2013-06-05 02:33:25 +08:00
|
|
|
// Expanded after instruction selection.
|
|
|
|
let Uses = [ICC], usesCustomInserter = 1 in {
|
2006-02-05 13:50:24 +08:00
|
|
|
def SELECT_CC_Int_ICC
|
Change instruction description to split OperandList into OutOperandList and
InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
llvm-svn: 40033
2007-07-19 09:14:50 +08:00
|
|
|
: Pseudo<(outs IntRegs:$dst), (ins IntRegs:$T, IntRegs:$F, i32imm:$Cond),
|
2006-02-05 13:50:24 +08:00
|
|
|
"; SELECT_CC_Int_ICC PSEUDO!",
|
2013-03-24 08:56:20 +08:00
|
|
|
[(set i32:$dst, (SPselecticc i32:$T, i32:$F, imm:$Cond))]>;
|
2011-01-12 06:38:28 +08:00
|
|
|
def SELECT_CC_FP_ICC
|
|
|
|
: Pseudo<(outs FPRegs:$dst), (ins FPRegs:$T, FPRegs:$F, i32imm:$Cond),
|
|
|
|
"; SELECT_CC_FP_ICC PSEUDO!",
|
2013-03-24 08:56:20 +08:00
|
|
|
[(set f32:$dst, (SPselecticc f32:$T, f32:$F, imm:$Cond))]>;
|
2011-01-12 06:38:28 +08:00
|
|
|
|
|
|
|
def SELECT_CC_DFP_ICC
|
|
|
|
: Pseudo<(outs DFPRegs:$dst), (ins DFPRegs:$T, DFPRegs:$F, i32imm:$Cond),
|
|
|
|
"; SELECT_CC_DFP_ICC PSEUDO!",
|
2013-03-24 08:56:20 +08:00
|
|
|
[(set f64:$dst, (SPselecticc f64:$T, f64:$F, imm:$Cond))]>;
|
2013-09-03 12:11:59 +08:00
|
|
|
|
|
|
|
def SELECT_CC_QFP_ICC
|
|
|
|
: Pseudo<(outs QFPRegs:$dst), (ins QFPRegs:$T, QFPRegs:$F, i32imm:$Cond),
|
|
|
|
"; SELECT_CC_QFP_ICC PSEUDO!",
|
|
|
|
[(set f128:$dst, (SPselecticc f128:$T, f128:$F, imm:$Cond))]>;
|
2011-01-12 06:38:28 +08:00
|
|
|
}
|
|
|
|
|
2014-03-02 10:12:33 +08:00
|
|
|
let usesCustomInserter = 1, Uses = [FCC0] in {
|
2011-01-12 06:38:28 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
def SELECT_CC_Int_FCC
|
Change instruction description to split OperandList into OutOperandList and
InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
llvm-svn: 40033
2007-07-19 09:14:50 +08:00
|
|
|
: Pseudo<(outs IntRegs:$dst), (ins IntRegs:$T, IntRegs:$F, i32imm:$Cond),
|
2006-02-05 13:50:24 +08:00
|
|
|
"; SELECT_CC_Int_FCC PSEUDO!",
|
2013-03-24 08:56:20 +08:00
|
|
|
[(set i32:$dst, (SPselectfcc i32:$T, i32:$F, imm:$Cond))]>;
|
2010-12-29 04:39:17 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
def SELECT_CC_FP_FCC
|
Change instruction description to split OperandList into OutOperandList and
InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
llvm-svn: 40033
2007-07-19 09:14:50 +08:00
|
|
|
: Pseudo<(outs FPRegs:$dst), (ins FPRegs:$T, FPRegs:$F, i32imm:$Cond),
|
2006-02-05 13:50:24 +08:00
|
|
|
"; SELECT_CC_FP_FCC PSEUDO!",
|
2013-03-24 08:56:20 +08:00
|
|
|
[(set f32:$dst, (SPselectfcc f32:$T, f32:$F, imm:$Cond))]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def SELECT_CC_DFP_FCC
|
Change instruction description to split OperandList into OutOperandList and
InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
llvm-svn: 40033
2007-07-19 09:14:50 +08:00
|
|
|
: Pseudo<(outs DFPRegs:$dst), (ins DFPRegs:$T, DFPRegs:$F, i32imm:$Cond),
|
2006-02-05 13:50:24 +08:00
|
|
|
"; SELECT_CC_DFP_FCC PSEUDO!",
|
2013-03-24 08:56:20 +08:00
|
|
|
[(set f64:$dst, (SPselectfcc f64:$T, f64:$F, imm:$Cond))]>;
|
2013-09-03 12:11:59 +08:00
|
|
|
def SELECT_CC_QFP_FCC
|
|
|
|
: Pseudo<(outs QFPRegs:$dst), (ins QFPRegs:$T, QFPRegs:$F, i32imm:$Cond),
|
|
|
|
"; SELECT_CC_QFP_FCC PSEUDO!",
|
|
|
|
[(set f128:$dst, (SPselectfcc f128:$T, f128:$F, imm:$Cond))]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
}
|
|
|
|
|
2016-05-04 17:33:30 +08:00
|
|
|
let hasSideEffects = 1, isBarrier = 1, usesCustomInserter = 1 in {
|
|
|
|
let Defs = [WIM] in
|
|
|
|
def EH_SJLJ_SETJMP32ri : Pseudo<(outs IntRegs:$dst), (ins MEMri:$buf),
|
|
|
|
"#EH_SJLJ_SETJMP32",
|
|
|
|
[(set i32:$dst, (SPsjlj_setjmp ADDRri:$buf))]>,
|
|
|
|
Requires<[Is32Bit]>;
|
|
|
|
def EH_SJLJ_SETJMP32rr : Pseudo<(outs IntRegs:$dst), (ins MEMrr:$buf),
|
|
|
|
"#EH_SJLJ_SETJMP32",
|
|
|
|
[(set i32:$dst, (SPsjlj_setjmp ADDRrr:$buf))]>,
|
|
|
|
Requires<[Is32Bit]>;
|
|
|
|
let isTerminator = 1 in
|
|
|
|
def EH_SJLJ_LONGJMP32ri : Pseudo<(outs), (ins MEMri:$buf),
|
|
|
|
"#EH_SJLJ_LONGJMP32",
|
|
|
|
[(SPsjlj_longjmp ADDRri:$buf)]>,
|
|
|
|
Requires<[Is32Bit]>;
|
|
|
|
def EH_SJLJ_LONGJMP32rr : Pseudo<(outs), (ins MEMrr:$buf),
|
|
|
|
"#EH_SJLJ_LONGJMP32",
|
|
|
|
[(SPsjlj_longjmp ADDRrr:$buf)]>,
|
|
|
|
Requires<[Is32Bit]>;
|
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.1 - Load Integer Instructions, p. 90
|
2014-03-01 15:46:33 +08:00
|
|
|
let DecoderMethod = "DecodeLoadInt" in {
|
Sparc: Add the "alternate address space" load/store instructions.
- Adds support for the asm syntax, which has an immediate integer
"ASI" (address space identifier) appearing after an address, before
a comma.
- Adds the various-width load, store, and swap in alternate address
space instructions. (ldsba, ldsha, lduba, lduha, lda, stba, stha,
sta, swapa)
This does not attempt to hook these instructions up to pointer address
spaces in LLVM, although that would probably be a reasonable thing to
do in the future.
Differential Revision: http://reviews.llvm.org/D8904
llvm-svn: 237581
2015-05-19 00:35:04 +08:00
|
|
|
defm LDSB : LoadA<"ldsb", 0b001001, 0b011001, sextloadi8, IntRegs, i32>;
|
|
|
|
defm LDSH : LoadA<"ldsh", 0b001010, 0b011010, sextloadi16, IntRegs, i32>;
|
|
|
|
defm LDUB : LoadA<"ldub", 0b000001, 0b010001, zextloadi8, IntRegs, i32>;
|
|
|
|
defm LDUH : LoadA<"lduh", 0b000010, 0b010010, zextloadi16, IntRegs, i32>;
|
|
|
|
defm LD : LoadA<"ld", 0b000000, 0b010000, load, IntRegs, i32>;
|
2014-03-01 15:46:33 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
let DecoderMethod = "DecodeLoadIntPair" in
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm LDD : LoadA<"ldd", 0b000011, 0b010011, load, IntPair, v2i32, IIC_ldd>;
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.2 - Load Floating-point Instructions, p. 92
|
2015-08-19 05:31:46 +08:00
|
|
|
let DecoderMethod = "DecodeLoadFP" in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm LDF : Load<"ld", 0b100000, load, FPRegs, f32, IIC_iu_or_fpu_instr>;
|
|
|
|
def LDFArr : LoadASI<"ld", 0b110000, load, FPRegs, f32, IIC_iu_or_fpu_instr>,
|
2015-08-19 05:31:46 +08:00
|
|
|
Requires<[HasV9]>;
|
|
|
|
}
|
|
|
|
let DecoderMethod = "DecodeLoadDFP" in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm LDDF : Load<"ldd", 0b100011, load, DFPRegs, f64, IIC_ldd>;
|
2015-08-19 23:59:49 +08:00
|
|
|
def LDDFArr : LoadASI<"ldd", 0b110011, load, DFPRegs, f64>,
|
2015-08-19 05:31:46 +08:00
|
|
|
Requires<[HasV9]>;
|
|
|
|
}
|
2014-03-01 15:46:33 +08:00
|
|
|
let DecoderMethod = "DecodeLoadQFP" in
|
2015-08-11 07:33:17 +08:00
|
|
|
defm LDQF : LoadA<"ldq", 0b100010, 0b110010, load, QFPRegs, f128>,
|
2014-03-01 15:46:33 +08:00
|
|
|
Requires<[HasV9, HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2016-02-27 20:49:59 +08:00
|
|
|
let DecoderMethod = "DecodeLoadCP" in
|
|
|
|
defm LDC : Load<"ld", 0b110000, load, CoprocRegs, i32>;
|
|
|
|
let DecoderMethod = "DecodeLoadCPPair" in
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm LDDC : Load<"ldd", 0b110011, load, CoprocPair, v2i32, IIC_ldd>;
|
2016-02-27 20:49:59 +08:00
|
|
|
|
|
|
|
let DecoderMethod = "DecodeLoadCP", Defs = [CPSR] in {
|
|
|
|
let rd = 0 in {
|
|
|
|
def LDCSRrr : F3_1<3, 0b110001, (outs), (ins MEMrr:$addr),
|
|
|
|
"ld [$addr], %csr", []>;
|
|
|
|
def LDCSRri : F3_2<3, 0b110001, (outs), (ins MEMri:$addr),
|
|
|
|
"ld [$addr], %csr", []>;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-20 02:34:48 +08:00
|
|
|
let DecoderMethod = "DecodeLoadFP" in
|
|
|
|
let Defs = [FSR] in {
|
|
|
|
let rd = 0 in {
|
|
|
|
def LDFSRrr : F3_1<3, 0b100001, (outs), (ins MEMrr:$addr),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"ld [$addr], %fsr", [], IIC_iu_or_fpu_instr>;
|
2015-08-20 02:34:48 +08:00
|
|
|
def LDFSRri : F3_2<3, 0b100001, (outs), (ins MEMri:$addr),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"ld [$addr], %fsr", [], IIC_iu_or_fpu_instr>;
|
2015-08-20 02:34:48 +08:00
|
|
|
}
|
|
|
|
let rd = 1 in {
|
|
|
|
def LDXFSRrr : F3_1<3, 0b100001, (outs), (ins MEMrr:$addr),
|
|
|
|
"ldx [$addr], %fsr", []>, Requires<[HasV9]>;
|
|
|
|
def LDXFSRri : F3_2<3, 0b100001, (outs), (ins MEMri:$addr),
|
|
|
|
"ldx [$addr], %fsr", []>, Requires<[HasV9]>;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.4 - Store Integer Instructions, p. 95
|
2014-03-01 15:46:33 +08:00
|
|
|
let DecoderMethod = "DecodeStoreInt" in {
|
Sparc: Add the "alternate address space" load/store instructions.
- Adds support for the asm syntax, which has an immediate integer
"ASI" (address space identifier) appearing after an address, before
a comma.
- Adds the various-width load, store, and swap in alternate address
space instructions. (ldsba, ldsha, lduba, lduha, lda, stba, stha,
sta, swapa)
This does not attempt to hook these instructions up to pointer address
spaces in LLVM, although that would probably be a reasonable thing to
do in the future.
Differential Revision: http://reviews.llvm.org/D8904
llvm-svn: 237581
2015-05-19 00:35:04 +08:00
|
|
|
defm STB : StoreA<"stb", 0b000101, 0b010101, truncstorei8, IntRegs, i32>;
|
|
|
|
defm STH : StoreA<"sth", 0b000110, 0b010110, truncstorei16, IntRegs, i32>;
|
|
|
|
defm ST : StoreA<"st", 0b000100, 0b010100, store, IntRegs, i32>;
|
2014-03-01 15:46:33 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
let DecoderMethod = "DecodeStoreIntPair" in
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm STD : StoreA<"std", 0b000111, 0b010111, store, IntPair, v2i32, IIC_std>;
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.5 - Store Floating-point Instructions, p. 97
|
2015-08-19 05:31:46 +08:00
|
|
|
let DecoderMethod = "DecodeStoreFP" in {
|
|
|
|
defm STF : Store<"st", 0b100100, store, FPRegs, f32>;
|
2015-08-19 23:59:49 +08:00
|
|
|
def STFArr : StoreASI<"st", 0b110100, store, FPRegs, f32>,
|
2015-08-19 05:31:46 +08:00
|
|
|
Requires<[HasV9]>;
|
|
|
|
}
|
|
|
|
let DecoderMethod = "DecodeStoreDFP" in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm STDF : Store<"std", 0b100111, store, DFPRegs, f64, IIC_std>;
|
2015-08-19 23:59:49 +08:00
|
|
|
def STDFArr : StoreASI<"std", 0b110111, store, DFPRegs, f64>,
|
2015-08-19 05:31:46 +08:00
|
|
|
Requires<[HasV9]>;
|
|
|
|
}
|
2014-03-01 15:46:33 +08:00
|
|
|
let DecoderMethod = "DecodeStoreQFP" in
|
2015-08-19 05:31:46 +08:00
|
|
|
defm STQF : StoreA<"stq", 0b100110, 0b110110, store, QFPRegs, f128>,
|
2014-03-01 15:46:33 +08:00
|
|
|
Requires<[HasV9, HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2016-02-27 20:49:59 +08:00
|
|
|
let DecoderMethod = "DecodeStoreCP" in
|
|
|
|
defm STC : Store<"st", 0b110100, store, CoprocRegs, i32>;
|
|
|
|
|
|
|
|
let DecoderMethod = "DecodeStoreCPPair" in
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm STDC : Store<"std", 0b110111, store, CoprocPair, v2i32, IIC_std>;
|
2016-02-27 20:49:59 +08:00
|
|
|
|
|
|
|
let DecoderMethod = "DecodeStoreCP", rd = 0 in {
|
|
|
|
let Defs = [CPSR] in {
|
|
|
|
def STCSRrr : F3_1<3, 0b110101, (outs MEMrr:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"st %csr, [$addr]", [], IIC_st>;
|
2016-02-27 20:49:59 +08:00
|
|
|
def STCSRri : F3_2<3, 0b110101, (outs MEMri:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"st %csr, [$addr]", [], IIC_st>;
|
2016-02-27 20:49:59 +08:00
|
|
|
}
|
|
|
|
let Defs = [CPQ] in {
|
|
|
|
def STDCQrr : F3_1<3, 0b110110, (outs MEMrr:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"std %cq, [$addr]", [], IIC_std>;
|
2016-02-27 20:49:59 +08:00
|
|
|
def STDCQri : F3_2<3, 0b110110, (outs MEMri:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"std %cq, [$addr]", [], IIC_std>;
|
2016-02-27 20:49:59 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
let DecoderMethod = "DecodeStoreFP" in {
|
|
|
|
let rd = 0 in {
|
|
|
|
let Defs = [FSR] in {
|
2015-09-16 21:30:54 +08:00
|
|
|
def STFSRrr : F3_1<3, 0b100101, (outs MEMrr:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"st %fsr, [$addr]", [], IIC_st>;
|
2015-09-16 21:30:54 +08:00
|
|
|
def STFSRri : F3_2<3, 0b100101, (outs MEMri:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"st %fsr, [$addr]", [], IIC_st>;
|
2015-09-16 21:30:54 +08:00
|
|
|
}
|
2016-02-27 20:49:59 +08:00
|
|
|
let Defs = [FQ] in {
|
|
|
|
def STDFQrr : F3_1<3, 0b100110, (outs MEMrr:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"std %fq, [$addr]", [], IIC_std>;
|
2016-02-27 20:49:59 +08:00
|
|
|
def STDFQri : F3_2<3, 0b100110, (outs MEMri:$addr), (ins),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"std %fq, [$addr]", [], IIC_std>;
|
2015-09-16 21:30:54 +08:00
|
|
|
}
|
|
|
|
}
|
2016-02-27 20:49:59 +08:00
|
|
|
let rd = 1, Defs = [FSR] in {
|
|
|
|
def STXFSRrr : F3_1<3, 0b100101, (outs MEMrr:$addr), (ins),
|
|
|
|
"stx %fsr, [$addr]", []>, Requires<[HasV9]>;
|
|
|
|
def STXFSRri : F3_2<3, 0b100101, (outs MEMri:$addr), (ins),
|
|
|
|
"stx %fsr, [$addr]", []>, Requires<[HasV9]>;
|
|
|
|
}
|
|
|
|
}
|
2015-09-16 21:30:54 +08:00
|
|
|
|
2015-07-01 22:38:07 +08:00
|
|
|
// Section B.8 - SWAP Register with Memory Instruction
|
|
|
|
// (Atomic swap)
|
|
|
|
let Constraints = "$val = $dst", DecoderMethod = "DecodeSWAP" in {
|
|
|
|
def SWAPrr : F3_1<3, 0b001111,
|
|
|
|
(outs IntRegs:$dst), (ins MEMrr:$addr, IntRegs:$val),
|
|
|
|
"swap [$addr], $dst",
|
|
|
|
[(set i32:$dst, (atomic_swap_32 ADDRrr:$addr, i32:$val))]>;
|
|
|
|
def SWAPri : F3_2<3, 0b001111,
|
|
|
|
(outs IntRegs:$dst), (ins MEMri:$addr, IntRegs:$val),
|
|
|
|
"swap [$addr], $dst",
|
|
|
|
[(set i32:$dst, (atomic_swap_32 ADDRri:$addr, i32:$val))]>;
|
|
|
|
def SWAPArr : F3_1_asi<3, 0b011111,
|
|
|
|
(outs IntRegs:$dst), (ins MEMrr:$addr, i8imm:$asi, IntRegs:$val),
|
|
|
|
"swapa [$addr] $asi, $dst",
|
|
|
|
[/*FIXME: pattern?*/]>;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.9 - SETHI Instruction, p. 104
|
|
|
|
def SETHIi: F2_1<0b100,
|
2013-10-08 15:15:22 +08:00
|
|
|
(outs IntRegs:$rd), (ins i32imm:$imm22),
|
|
|
|
"sethi $imm22, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set i32:$rd, SETHIimm:$imm22)],
|
|
|
|
IIC_iu_instr>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Section B.10 - NOP Instruction, p. 105
|
|
|
|
// (It's a special case of SETHI)
|
|
|
|
let rd = 0, imm22 = 0 in
|
Change instruction description to split OperandList into OutOperandList and
InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
"add{l} {$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
llvm-svn: 40033
2007-07-19 09:14:50 +08:00
|
|
|
def NOP : F2_1<0b100, (outs), (ins), "nop", []>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Section B.11 - Logical Instructions, p. 106
|
2014-03-01 17:11:57 +08:00
|
|
|
defm AND : F3_12<"and", 0b000001, and, IntRegs, i32, simm13Op>;
|
2006-09-02 06:28:02 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
def ANDNrr : F3_1<2, 0b000101,
|
2014-01-06 16:08:58 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"andn $rs1, $rs2, $rd",
|
|
|
|
[(set i32:$rd, (and i32:$rs1, (not i32:$rs2)))]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def ANDNri : F3_2<2, 0b000101,
|
2014-03-01 17:11:57 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13),
|
2014-01-06 16:08:58 +08:00
|
|
|
"andn $rs1, $simm13, $rd", []>;
|
2006-09-02 06:28:02 +08:00
|
|
|
|
2014-03-01 17:11:57 +08:00
|
|
|
defm OR : F3_12<"or", 0b000010, or, IntRegs, i32, simm13Op>;
|
2006-09-02 06:28:02 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
def ORNrr : F3_1<2, 0b000110,
|
2014-01-06 16:08:58 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"orn $rs1, $rs2, $rd",
|
|
|
|
[(set i32:$rd, (or i32:$rs1, (not i32:$rs2)))]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def ORNri : F3_2<2, 0b000110,
|
2014-03-01 17:11:57 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13),
|
2014-01-06 16:08:58 +08:00
|
|
|
"orn $rs1, $simm13, $rd", []>;
|
2014-03-01 17:11:57 +08:00
|
|
|
defm XOR : F3_12<"xor", 0b000011, xor, IntRegs, i32, simm13Op>;
|
2006-09-02 06:28:02 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
def XNORrr : F3_1<2, 0b000111,
|
2014-01-06 16:08:58 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"xnor $rs1, $rs2, $rd",
|
|
|
|
[(set i32:$rd, (not (xor i32:$rs1, i32:$rs2)))]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def XNORri : F3_2<2, 0b000111,
|
2014-03-01 17:11:57 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13),
|
2014-01-06 16:08:58 +08:00
|
|
|
"xnor $rs1, $simm13, $rd", []>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2014-03-02 01:51:00 +08:00
|
|
|
let Defs = [ICC] in {
|
|
|
|
defm ANDCC : F3_12np<"andcc", 0b010001>;
|
|
|
|
defm ANDNCC : F3_12np<"andncc", 0b010101>;
|
|
|
|
defm ORCC : F3_12np<"orcc", 0b010010>;
|
|
|
|
defm ORNCC : F3_12np<"orncc", 0b010110>;
|
|
|
|
defm XORCC : F3_12np<"xorcc", 0b010011>;
|
|
|
|
defm XNORCC : F3_12np<"xnorcc", 0b010111>;
|
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.12 - Shift Instructions, p. 107
|
2014-03-01 17:11:57 +08:00
|
|
|
defm SLL : F3_12<"sll", 0b100101, shl, IntRegs, i32, simm13Op>;
|
|
|
|
defm SRL : F3_12<"srl", 0b100110, srl, IntRegs, i32, simm13Op>;
|
|
|
|
defm SRA : F3_12<"sra", 0b100111, sra, IntRegs, i32, simm13Op>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Section B.13 - Add Instructions, p. 108
|
2014-03-01 17:11:57 +08:00
|
|
|
defm ADD : F3_12<"add", 0b000000, add, IntRegs, i32, simm13Op>;
|
2006-02-10 15:35:42 +08:00
|
|
|
|
|
|
|
// "LEA" forms of add (patterns to make tblgen happy)
|
2014-01-04 19:30:13 +08:00
|
|
|
let Predicates = [Is32Bit], isCodeGenOnly = 1 in
|
2013-11-25 04:07:35 +08:00
|
|
|
def LEA_ADDri : F3_2<2, 0b000000,
|
|
|
|
(outs IntRegs:$dst), (ins MEMri:$addr),
|
|
|
|
"add ${addr:arith}, $dst",
|
|
|
|
[(set iPTR:$dst, ADDRri:$addr)]>;
|
2009-09-16 01:46:24 +08:00
|
|
|
|
2013-06-05 02:33:25 +08:00
|
|
|
let Defs = [ICC] in
|
2014-03-01 17:11:57 +08:00
|
|
|
defm ADDCC : F3_12<"addcc", 0b010000, addc, IntRegs, i32, simm13Op>;
|
2009-09-16 01:46:24 +08:00
|
|
|
|
2014-03-02 01:51:00 +08:00
|
|
|
let Uses = [ICC] in
|
|
|
|
defm ADDC : F3_12np<"addx", 0b001000>;
|
|
|
|
|
2013-10-06 10:11:10 +08:00
|
|
|
let Uses = [ICC], Defs = [ICC] in
|
2014-03-01 17:11:57 +08:00
|
|
|
defm ADDE : F3_12<"addxcc", 0b011000, adde, IntRegs, i32, simm13Op>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Section B.15 - Subtract Instructions, p. 110
|
2014-03-01 17:11:57 +08:00
|
|
|
defm SUB : F3_12 <"sub" , 0b000100, sub, IntRegs, i32, simm13Op>;
|
2013-10-06 10:11:10 +08:00
|
|
|
let Uses = [ICC], Defs = [ICC] in
|
2014-03-01 17:11:57 +08:00
|
|
|
defm SUBE : F3_12 <"subxcc" , 0b011100, sube, IntRegs, i32, simm13Op>;
|
2006-09-02 06:28:02 +08:00
|
|
|
|
2013-09-22 17:54:42 +08:00
|
|
|
let Defs = [ICC] in
|
2014-03-01 17:11:57 +08:00
|
|
|
defm SUBCC : F3_12 <"subcc", 0b010100, subc, IntRegs, i32, simm13Op>;
|
2013-06-07 08:03:36 +08:00
|
|
|
|
2014-03-02 01:51:00 +08:00
|
|
|
let Uses = [ICC] in
|
|
|
|
defm SUBC : F3_12np <"subx", 0b001100>;
|
|
|
|
|
2015-07-07 00:01:07 +08:00
|
|
|
// cmp (from Section A.3) is a specialized alias for subcc
|
2013-09-22 17:54:42 +08:00
|
|
|
let Defs = [ICC], rd = 0 in {
|
2013-06-07 08:03:36 +08:00
|
|
|
def CMPrr : F3_1<2, 0b010100,
|
2014-01-06 16:08:58 +08:00
|
|
|
(outs), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"cmp $rs1, $rs2",
|
|
|
|
[(SPcmpicc i32:$rs1, i32:$rs2)]>;
|
2013-09-23 02:54:54 +08:00
|
|
|
def CMPri : F3_2<2, 0b010100,
|
2014-03-01 17:11:57 +08:00
|
|
|
(outs), (ins IntRegs:$rs1, simm13Op:$simm13),
|
2014-01-06 16:08:58 +08:00
|
|
|
"cmp $rs1, $simm13",
|
|
|
|
[(SPcmpicc i32:$rs1, (i32 simm13:$simm13))]>;
|
2013-06-07 08:03:36 +08:00
|
|
|
}
|
2009-09-16 01:46:24 +08:00
|
|
|
|
2010-12-29 04:39:17 +08:00
|
|
|
// Section B.18 - Multiply Instructions, p. 113
|
|
|
|
let Defs = [Y] in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm UMUL : F3_12np<"umul", 0b001010, IIC_iu_umul>;
|
|
|
|
defm SMUL : F3_12 <"smul", 0b001011, mul, IntRegs, i32, simm13Op, IIC_iu_smul>;
|
2010-12-29 04:39:17 +08:00
|
|
|
}
|
2006-02-09 13:06:36 +08:00
|
|
|
|
2014-03-02 01:51:00 +08:00
|
|
|
let Defs = [Y, ICC] in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm UMULCC : F3_12np<"umulcc", 0b011010, IIC_iu_umul>;
|
|
|
|
defm SMULCC : F3_12np<"smulcc", 0b011011, IIC_iu_smul>;
|
2014-03-02 01:51:00 +08:00
|
|
|
}
|
|
|
|
|
2015-09-18 04:54:26 +08:00
|
|
|
let Defs = [Y, ICC], Uses = [Y, ICC] in {
|
|
|
|
defm MULSCC : F3_12np<"mulscc", 0b100100>;
|
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.19 - Divide Instructions, p. 115
|
2015-07-09 00:25:12 +08:00
|
|
|
let Uses = [Y], Defs = [Y] in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm UDIV : F3_12np<"udiv", 0b001110, IIC_iu_div>;
|
|
|
|
defm SDIV : F3_12np<"sdiv", 0b001111, IIC_iu_div>;
|
2010-12-29 04:39:17 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2015-07-09 00:25:12 +08:00
|
|
|
let Uses = [Y], Defs = [Y, ICC] in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
defm UDIVCC : F3_12np<"udivcc", 0b011110, IIC_iu_div>;
|
|
|
|
defm SDIVCC : F3_12np<"sdivcc", 0b011111, IIC_iu_div>;
|
2014-03-02 01:51:00 +08:00
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.20 - SAVE and RESTORE, p. 117
|
2006-09-02 06:28:02 +08:00
|
|
|
defm SAVE : F3_12np<"save" , 0b111100>;
|
|
|
|
defm RESTORE : F3_12np<"restore", 0b111101>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Section B.21 - Branch on Integer Condition Codes Instructions, p. 119
|
|
|
|
|
2013-09-22 16:51:55 +08:00
|
|
|
// unconditional branch class.
|
|
|
|
class BranchAlways<dag ins, string asmstr, list<dag> pattern>
|
2014-03-02 04:08:48 +08:00
|
|
|
: F2_2<0b010, 0, (outs), ins, asmstr, pattern> {
|
2013-09-22 16:51:55 +08:00
|
|
|
let isBranch = 1;
|
|
|
|
let isTerminator = 1;
|
|
|
|
let hasDelaySlot = 1;
|
|
|
|
let isBarrier = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
let cond = 8 in
|
|
|
|
def BA : BranchAlways<(ins brtarget:$imm22), "ba $imm22", [(br bb:$imm22)]>;
|
|
|
|
|
2014-03-02 06:03:07 +08:00
|
|
|
|
|
|
|
let isBranch = 1, isTerminator = 1, hasDelaySlot = 1 in {
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// conditional branch class:
|
2013-09-22 16:51:55 +08:00
|
|
|
class BranchSP<dag ins, string asmstr, list<dag> pattern>
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
: F2_2<0b010, 0, (outs), ins, asmstr, pattern, IIC_iu_instr>;
|
2014-03-02 04:08:48 +08:00
|
|
|
|
|
|
|
// conditional branch with annul class:
|
|
|
|
class BranchSPA<dag ins, string asmstr, list<dag> pattern>
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
: F2_2<0b010, 1, (outs), ins, asmstr, pattern, IIC_iu_instr>;
|
2014-03-02 06:03:07 +08:00
|
|
|
|
|
|
|
// Conditional branch class on %icc|%xcc with predication:
|
|
|
|
multiclass IPredBranch<string regstr, list<dag> CCPattern> {
|
|
|
|
def CC : F2_3<0b001, 0, 1, (outs), (ins bprtarget:$imm19, CCOp:$cond),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
!strconcat("b$cond ", !strconcat(regstr, ", $imm19")),
|
|
|
|
CCPattern,
|
|
|
|
IIC_iu_instr>;
|
2014-03-02 06:03:07 +08:00
|
|
|
def CCA : F2_3<0b001, 1, 1, (outs), (ins bprtarget:$imm19, CCOp:$cond),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
!strconcat("b$cond,a ", !strconcat(regstr, ", $imm19")),
|
|
|
|
[],
|
|
|
|
IIC_iu_instr>;
|
2014-03-02 06:03:07 +08:00
|
|
|
def CCNT : F2_3<0b001, 0, 0, (outs), (ins bprtarget:$imm19, CCOp:$cond),
|
|
|
|
!strconcat("b$cond,pn ", !strconcat(regstr, ", $imm19")),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[],
|
|
|
|
IIC_iu_instr>;
|
2014-03-02 06:03:07 +08:00
|
|
|
def CCANT : F2_3<0b001, 1, 0, (outs), (ins bprtarget:$imm19, CCOp:$cond),
|
|
|
|
!strconcat("b$cond,a,pn ", !strconcat(regstr, ", $imm19")),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[],
|
|
|
|
IIC_iu_instr>;
|
2006-02-05 13:50:24 +08:00
|
|
|
}
|
|
|
|
|
2014-03-02 06:03:07 +08:00
|
|
|
} // let isBranch = 1, isTerminator = 1, hasDelaySlot = 1
|
|
|
|
|
|
|
|
|
2013-06-05 02:33:25 +08:00
|
|
|
// Indirect branch instructions.
|
2014-01-10 09:48:17 +08:00
|
|
|
let isTerminator = 1, isBarrier = 1, hasDelaySlot = 1, isBranch =1,
|
|
|
|
isIndirectBranch = 1, rd = 0, isCodeGenOnly = 1 in {
|
2013-06-03 13:58:33 +08:00
|
|
|
def BINDrr : F3_1<2, 0b111000,
|
|
|
|
(outs), (ins MEMrr:$ptr),
|
|
|
|
"jmp $ptr",
|
|
|
|
[(brind ADDRrr:$ptr)]>;
|
|
|
|
def BINDri : F3_2<2, 0b111000,
|
|
|
|
(outs), (ins MEMri:$ptr),
|
|
|
|
"jmp $ptr",
|
|
|
|
[(brind ADDRri:$ptr)]>;
|
|
|
|
}
|
|
|
|
|
2014-03-02 04:08:48 +08:00
|
|
|
let Uses = [ICC] in {
|
2013-09-22 16:51:55 +08:00
|
|
|
def BCOND : BranchSP<(ins brtarget:$imm22, CCOp:$cond),
|
|
|
|
"b$cond $imm22",
|
|
|
|
[(SPbricc bb:$imm22, imm:$cond)]>;
|
2014-03-02 04:08:48 +08:00
|
|
|
def BCONDA : BranchSPA<(ins brtarget:$imm22, CCOp:$cond),
|
|
|
|
"b$cond,a $imm22", []>;
|
2014-03-02 06:03:07 +08:00
|
|
|
|
|
|
|
let Predicates = [HasV9], cc = 0b00 in
|
|
|
|
defm BPI : IPredBranch<"%icc", []>;
|
2014-03-02 04:08:48 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Section B.22 - Branch on Floating-point Condition Codes Instructions, p. 121
|
|
|
|
|
2014-03-02 06:03:07 +08:00
|
|
|
let isBranch = 1, isTerminator = 1, hasDelaySlot = 1 in {
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// floating-point conditional branch class:
|
2013-09-22 16:51:55 +08:00
|
|
|
class FPBranchSP<dag ins, string asmstr, list<dag> pattern>
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
: F2_2<0b110, 0, (outs), ins, asmstr, pattern, IIC_fpu_normal_instr>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2014-03-02 04:08:48 +08:00
|
|
|
// floating-point conditional branch with annul class:
|
|
|
|
class FPBranchSPA<dag ins, string asmstr, list<dag> pattern>
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
: F2_2<0b110, 1, (outs), ins, asmstr, pattern, IIC_fpu_normal_instr>;
|
2014-03-02 06:03:07 +08:00
|
|
|
|
|
|
|
// Conditional branch class on %fcc0-%fcc3 with predication:
|
|
|
|
multiclass FPredBranch {
|
2014-03-02 12:43:45 +08:00
|
|
|
def CC : F2_3<0b101, 0, 1, (outs), (ins bprtarget:$imm19, CCOp:$cond,
|
|
|
|
FCCRegs:$cc),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"fb$cond $cc, $imm19", [], IIC_fpu_normal_instr>;
|
2014-03-02 12:43:45 +08:00
|
|
|
def CCA : F2_3<0b101, 1, 1, (outs), (ins bprtarget:$imm19, CCOp:$cond,
|
|
|
|
FCCRegs:$cc),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"fb$cond,a $cc, $imm19", [], IIC_fpu_normal_instr>;
|
2014-03-02 12:43:45 +08:00
|
|
|
def CCNT : F2_3<0b101, 0, 0, (outs), (ins bprtarget:$imm19, CCOp:$cond,
|
|
|
|
FCCRegs:$cc),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"fb$cond,pn $cc, $imm19", [], IIC_fpu_normal_instr>;
|
2014-03-02 12:43:45 +08:00
|
|
|
def CCANT : F2_3<0b101, 1, 0, (outs), (ins bprtarget:$imm19, CCOp:$cond,
|
|
|
|
FCCRegs:$cc),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"fb$cond,a,pn $cc, $imm19", [], IIC_fpu_normal_instr>;
|
2014-03-02 04:08:48 +08:00
|
|
|
}
|
2014-03-02 06:03:07 +08:00
|
|
|
} // let isBranch = 1, isTerminator = 1, hasDelaySlot = 1
|
2014-03-02 04:08:48 +08:00
|
|
|
|
2014-03-02 10:12:33 +08:00
|
|
|
let Uses = [FCC0] in {
|
2013-09-22 16:51:55 +08:00
|
|
|
def FBCOND : FPBranchSP<(ins brtarget:$imm22, CCOp:$cond),
|
|
|
|
"fb$cond $imm22",
|
|
|
|
[(SPbrfcc bb:$imm22, imm:$cond)]>;
|
2014-03-02 04:08:48 +08:00
|
|
|
def FBCONDA : FPBranchSPA<(ins brtarget:$imm22, CCOp:$cond),
|
|
|
|
"fb$cond,a $imm22", []>;
|
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2014-03-02 12:43:45 +08:00
|
|
|
let Predicates = [HasV9] in
|
|
|
|
defm BPF : FPredBranch;
|
|
|
|
|
2016-02-27 20:49:59 +08:00
|
|
|
// Section B.22 - Branch on Co-processor Condition Codes Instructions, p. 123
|
|
|
|
let isBranch = 1, isTerminator = 1, hasDelaySlot = 1 in {
|
|
|
|
|
|
|
|
// co-processor conditional branch class:
|
|
|
|
class CPBranchSP<dag ins, string asmstr, list<dag> pattern>
|
|
|
|
: F2_2<0b111, 0, (outs), ins, asmstr, pattern>;
|
|
|
|
|
|
|
|
// co-processor conditional branch with annul class:
|
|
|
|
class CPBranchSPA<dag ins, string asmstr, list<dag> pattern>
|
|
|
|
: F2_2<0b111, 1, (outs), ins, asmstr, pattern>;
|
|
|
|
|
|
|
|
} // let isBranch = 1, isTerminator = 1, hasDelaySlot = 1
|
2014-03-02 12:43:45 +08:00
|
|
|
|
2016-02-27 20:49:59 +08:00
|
|
|
def CBCOND : CPBranchSP<(ins brtarget:$imm22, CCOp:$cond),
|
|
|
|
"cb$cond $imm22",
|
|
|
|
[(SPbrfcc bb:$imm22, imm:$cond)]>;
|
|
|
|
def CBCONDA : CPBranchSPA<(ins brtarget:$imm22, CCOp:$cond),
|
|
|
|
"cb$cond,a $imm22", []>;
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.24 - Call and Link Instruction, p. 125
|
|
|
|
// This is the only Format 1 instruction
|
2011-01-12 11:18:21 +08:00
|
|
|
let Uses = [O6],
|
2013-08-23 10:33:47 +08:00
|
|
|
hasDelaySlot = 1, isCall = 1 in {
|
2014-03-01 16:30:58 +08:00
|
|
|
def CALL : InstSP<(outs), (ins calltarget:$disp, variable_ops),
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
"call $disp",
|
|
|
|
[],
|
|
|
|
IIC_jmp_or_call> {
|
2006-02-05 13:50:24 +08:00
|
|
|
bits<30> disp;
|
|
|
|
let op = 1;
|
|
|
|
let Inst{29-0} = disp;
|
|
|
|
}
|
2013-06-05 02:33:25 +08:00
|
|
|
|
2014-01-10 09:48:17 +08:00
|
|
|
// indirect calls: special cases of JMPL.
|
|
|
|
let isCodeGenOnly = 1, rd = 15 in {
|
|
|
|
def CALLrr : F3_1<2, 0b111000,
|
|
|
|
(outs), (ins MEMrr:$ptr, variable_ops),
|
|
|
|
"call $ptr",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(call ADDRrr:$ptr)],
|
|
|
|
IIC_jmp_or_call>;
|
2014-01-10 09:48:17 +08:00
|
|
|
def CALLri : F3_2<2, 0b111000,
|
|
|
|
(outs), (ins MEMri:$ptr, variable_ops),
|
|
|
|
"call $ptr",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(call ADDRri:$ptr)],
|
|
|
|
IIC_jmp_or_call>;
|
2014-01-10 09:48:17 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
}
|
|
|
|
|
2015-07-01 22:38:07 +08:00
|
|
|
// Section B.25 - Jump and Link Instruction
|
|
|
|
|
|
|
|
// JMPL Instruction.
|
|
|
|
let isTerminator = 1, hasDelaySlot = 1, isBarrier = 1,
|
|
|
|
DecoderMethod = "DecodeJMPL" in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
def JMPLrr: F3_1<2, 0b111000,
|
|
|
|
(outs IntRegs:$dst), (ins MEMrr:$addr),
|
|
|
|
"jmpl $addr, $dst",
|
|
|
|
[],
|
|
|
|
IIC_jmp_or_call>;
|
|
|
|
def JMPLri: F3_2<2, 0b111000,
|
|
|
|
(outs IntRegs:$dst), (ins MEMri:$addr),
|
|
|
|
"jmpl $addr, $dst",
|
|
|
|
[],
|
|
|
|
IIC_jmp_or_call>;
|
2015-07-01 22:38:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Section A.3 - Synthetic Instructions, p. 85
|
|
|
|
// special cases of JMPL:
|
|
|
|
let isReturn = 1, isTerminator = 1, hasDelaySlot = 1, isBarrier = 1,
|
|
|
|
isCodeGenOnly = 1 in {
|
|
|
|
let rd = 0, rs1 = 15 in
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
def RETL: F3_2<2, 0b111000,
|
|
|
|
(outs), (ins i32imm:$val),
|
|
|
|
"jmp %o7+$val",
|
|
|
|
[(retflag simm13:$val)],
|
|
|
|
IIC_jmp_or_call>;
|
2015-07-01 22:38:07 +08:00
|
|
|
|
|
|
|
let rd = 0, rs1 = 31 in
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
def RET: F3_2<2, 0b111000,
|
|
|
|
(outs), (ins i32imm:$val),
|
|
|
|
"jmp %i7+$val",
|
|
|
|
[],
|
|
|
|
IIC_jmp_or_call>;
|
2015-07-01 22:38:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Section B.26 - Return from Trap Instruction
|
|
|
|
let isReturn = 1, isTerminator = 1, hasDelaySlot = 1,
|
|
|
|
isBarrier = 1, rd = 0, DecoderMethod = "DecodeReturn" in {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
def RETTrr : F3_1<2, 0b111001,
|
|
|
|
(outs), (ins MEMrr:$addr),
|
|
|
|
"rett $addr",
|
|
|
|
[],
|
|
|
|
IIC_jmp_or_call>;
|
|
|
|
def RETTri : F3_2<2, 0b111001,
|
|
|
|
(outs), (ins MEMri:$addr),
|
|
|
|
"rett $addr",
|
|
|
|
[],
|
|
|
|
IIC_jmp_or_call>;
|
2015-07-01 22:38:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// Section B.27 - Trap on Integer Condition Codes Instruction
|
2016-03-10 02:20:21 +08:00
|
|
|
// conditional branch class:
|
|
|
|
let DecoderNamespace = "SparcV8", DecoderMethod = "DecodeTRAP", hasSideEffects = 1, Uses = [ICC], cc = 0b00 in
|
|
|
|
{
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
def TRAPrr : TRAPSPrr<0b111010,
|
|
|
|
(outs), (ins IntRegs:$rs1, IntRegs:$rs2, CCOp:$cond),
|
|
|
|
"t$cond $rs1 + $rs2",
|
|
|
|
[]>;
|
|
|
|
def TRAPri : TRAPSPri<0b111010,
|
|
|
|
(outs), (ins IntRegs:$rs1, i32imm:$imm, CCOp:$cond),
|
|
|
|
"t$cond $rs1 + $imm",
|
|
|
|
[]>;
|
2016-03-10 02:20:21 +08:00
|
|
|
}
|
|
|
|
|
2015-07-01 22:38:07 +08:00
|
|
|
multiclass TRAP<string regStr> {
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
def rr : TRAPSPrr<0b111010,
|
|
|
|
(outs), (ins IntRegs:$rs1, IntRegs:$rs2, CCOp:$cond),
|
|
|
|
!strconcat(!strconcat("t$cond ", regStr), ", $rs1 + $rs2"),
|
|
|
|
[]>;
|
|
|
|
def ri : TRAPSPri<0b111010,
|
|
|
|
(outs), (ins IntRegs:$rs1, i32imm:$imm, CCOp:$cond),
|
|
|
|
!strconcat(!strconcat("t$cond ", regStr), ", $rs1 + $imm"),
|
|
|
|
[]>;
|
2015-07-01 22:38:07 +08:00
|
|
|
}
|
|
|
|
|
2016-03-10 02:20:21 +08:00
|
|
|
let DecoderNamespace = "SparcV9", DecoderMethod = "DecodeTRAP", Predicates = [HasV9], hasSideEffects = 1, Uses = [ICC], cc = 0b00 in
|
2015-07-01 22:38:07 +08:00
|
|
|
defm TICC : TRAP<"%icc">;
|
|
|
|
|
2016-03-10 02:20:21 +08:00
|
|
|
|
2015-07-01 22:38:07 +08:00
|
|
|
let isBarrier = 1, isTerminator = 1, rd = 0b01000, rs1 = 0, simm13 = 5 in
|
|
|
|
def TA5 : F3_2<0b10, 0b111010, (outs), (ins), "ta 5", [(trap)]>;
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.28 - Read State Register Instructions
|
2015-05-19 00:29:48 +08:00
|
|
|
let rs2 = 0 in
|
|
|
|
def RDASR : F3_1<2, 0b101000,
|
|
|
|
(outs IntRegs:$rd), (ins ASRRegs:$rs1),
|
|
|
|
"rd $rs1, $rd", []>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2015-05-19 00:38:47 +08:00
|
|
|
// PSR, WIM, and TBR don't exist on the SparcV9, only the V8.
|
|
|
|
let Predicates = [HasNoV9] in {
|
|
|
|
let rs2 = 0, rs1 = 0, Uses=[PSR] in
|
|
|
|
def RDPSR : F3_1<2, 0b101001,
|
|
|
|
(outs IntRegs:$rd), (ins),
|
|
|
|
"rd %psr, $rd", []>;
|
|
|
|
|
|
|
|
let rs2 = 0, rs1 = 0, Uses=[WIM] in
|
|
|
|
def RDWIM : F3_1<2, 0b101010,
|
|
|
|
(outs IntRegs:$rd), (ins),
|
|
|
|
"rd %wim, $rd", []>;
|
|
|
|
|
|
|
|
let rs2 = 0, rs1 = 0, Uses=[TBR] in
|
|
|
|
def RDTBR : F3_1<2, 0b101011,
|
|
|
|
(outs IntRegs:$rd), (ins),
|
|
|
|
"rd %tbr, $rd", []>;
|
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Section B.29 - Write State Register Instructions
|
2015-05-19 00:29:48 +08:00
|
|
|
def WRASRrr : F3_1<2, 0b110000,
|
|
|
|
(outs ASRRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"wr $rs1, $rs2, $rd", []>;
|
|
|
|
def WRASRri : F3_2<2, 0b110000,
|
|
|
|
(outs ASRRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13),
|
|
|
|
"wr $rs1, $simm13, $rd", []>;
|
|
|
|
|
2015-05-19 00:38:47 +08:00
|
|
|
// PSR, WIM, and TBR don't exist on the SparcV9, only the V8.
|
|
|
|
let Predicates = [HasNoV9] in {
|
|
|
|
let Defs = [PSR], rd=0 in {
|
|
|
|
def WRPSRrr : F3_1<2, 0b110001,
|
|
|
|
(outs), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"wr $rs1, $rs2, %psr", []>;
|
|
|
|
def WRPSRri : F3_2<2, 0b110001,
|
|
|
|
(outs), (ins IntRegs:$rs1, simm13Op:$simm13),
|
|
|
|
"wr $rs1, $simm13, %psr", []>;
|
|
|
|
}
|
|
|
|
|
|
|
|
let Defs = [WIM], rd=0 in {
|
|
|
|
def WRWIMrr : F3_1<2, 0b110010,
|
|
|
|
(outs), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"wr $rs1, $rs2, %wim", []>;
|
|
|
|
def WRWIMri : F3_2<2, 0b110010,
|
|
|
|
(outs), (ins IntRegs:$rs1, simm13Op:$simm13),
|
|
|
|
"wr $rs1, $simm13, %wim", []>;
|
|
|
|
}
|
|
|
|
|
|
|
|
let Defs = [TBR], rd=0 in {
|
|
|
|
def WRTBRrr : F3_1<2, 0b110011,
|
|
|
|
(outs), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"wr $rs1, $rs2, %tbr", []>;
|
|
|
|
def WRTBRri : F3_2<2, 0b110011,
|
|
|
|
(outs), (ins IntRegs:$rs1, simm13Op:$simm13),
|
|
|
|
"wr $rs1, $simm13, %tbr", []>;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-01 22:38:07 +08:00
|
|
|
// Section B.30 - STBAR Instruction
|
|
|
|
let hasSideEffects = 1, rd = 0, rs1 = 0b01111, rs2 = 0 in
|
|
|
|
def STBAR : F3_1<2, 0b101000, (outs), (ins), "stbar", []>;
|
|
|
|
|
|
|
|
|
|
|
|
// Section B.31 - Unimplmented Instruction
|
|
|
|
let rd = 0 in
|
|
|
|
def UNIMP : F2_1<0b000, (outs), (ins i32imm:$imm22),
|
|
|
|
"unimp $imm22", []>;
|
|
|
|
|
2015-07-07 00:01:04 +08:00
|
|
|
// Section B.32 - Flush Instruction Memory
|
|
|
|
let rd = 0 in {
|
|
|
|
def FLUSHrr : F3_1<2, 0b111011, (outs), (ins MEMrr:$addr),
|
|
|
|
"flush $addr", []>;
|
|
|
|
def FLUSHri : F3_2<2, 0b111011, (outs), (ins MEMri:$addr),
|
|
|
|
"flush $addr", []>;
|
|
|
|
|
|
|
|
// The no-arg FLUSH is only here for the benefit of the InstAlias
|
|
|
|
// "flush", which cannot seem to use FLUSHrr, due to the inability
|
|
|
|
// to construct a MEMrr with fixed G0 registers.
|
|
|
|
let rs1 = 0, rs2 = 0 in
|
|
|
|
def FLUSH : F3_1<2, 0b111011, (outs), (ins), "flush %g0", []>;
|
|
|
|
}
|
|
|
|
|
2015-07-01 22:38:07 +08:00
|
|
|
// Section B.33 - Floating-point Operate (FPop) Instructions
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Convert Integer to Floating-point Instructions, p. 141
|
2013-09-22 17:54:42 +08:00
|
|
|
def FITOS : F3_3u<2, 0b110100, 0b011000100,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fitos $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set FPRegs:$rd, (SPitof FPRegs:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FITOD : F3_3u<2, 0b110100, 0b011001000,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fitod $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set DFPRegs:$rd, (SPitof FPRegs:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FITOQ : F3_3u<2, 0b110100, 0b011001100,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fitoq $rs2, $rd",
|
|
|
|
[(set QFPRegs:$rd, (SPitof FPRegs:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Convert Floating-point to Integer Instructions, p. 142
|
2013-09-22 17:54:42 +08:00
|
|
|
def FSTOI : F3_3u<2, 0b110100, 0b011010001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fstoi $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set FPRegs:$rd, (SPftoi FPRegs:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FDTOI : F3_3u<2, 0b110100, 0b011010010,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins DFPRegs:$rs2),
|
|
|
|
"fdtoi $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set FPRegs:$rd, (SPftoi DFPRegs:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FQTOI : F3_3u<2, 0b110100, 0b011010011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins QFPRegs:$rs2),
|
|
|
|
"fqtoi $rs2, $rd",
|
|
|
|
[(set FPRegs:$rd, (SPftoi QFPRegs:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Convert between Floating-point Formats Instructions, p. 143
|
2013-09-22 17:54:42 +08:00
|
|
|
def FSTOD : F3_3u<2, 0b110100, 0b011001001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fstod $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f64:$rd, (fpextend f32:$rs2))],
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
IIC_fpu_stod>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FSTOQ : F3_3u<2, 0b110100, 0b011001101,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fstoq $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f128:$rd, (fpextend f32:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FDTOS : F3_3u<2, 0b110100, 0b011000110,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins DFPRegs:$rs2),
|
|
|
|
"fdtos $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f32:$rd, (fpround f64:$rs2))],
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
IIC_fpu_fast_instr>;
|
2014-01-12 12:48:54 +08:00
|
|
|
def FDTOQ : F3_3u<2, 0b110100, 0b011001110,
|
|
|
|
(outs QFPRegs:$rd), (ins DFPRegs:$rs2),
|
|
|
|
"fdtoq $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f128:$rd, (fpextend f64:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FQTOS : F3_3u<2, 0b110100, 0b011000111,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins QFPRegs:$rs2),
|
|
|
|
"fqtos $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f32:$rd, (fpround f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FQTOD : F3_3u<2, 0b110100, 0b011001011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins QFPRegs:$rs2),
|
|
|
|
"fqtod $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f64:$rd, (fpround f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Floating-point Move Instructions, p. 144
|
2013-09-22 17:54:42 +08:00
|
|
|
def FMOVS : F3_3u<2, 0b110100, 0b000000001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fmovs $rs2, $rd", []>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FNEGS : F3_3u<2, 0b110100, 0b000000101,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fnegs $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f32:$rd, (fneg f32:$rs2))],
|
|
|
|
IIC_fpu_negs>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FABSS : F3_3u<2, 0b110100, 0b000001001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fabss $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f32:$rd, (fabs f32:$rs2))],
|
|
|
|
IIC_fpu_abs>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
// Floating-point Square Root Instructions, p.145
|
2016-06-19 19:03:28 +08:00
|
|
|
// FSQRTS generates an erratum on LEON processors, so by disabling this instruction
|
|
|
|
// this will be promoted to use FSQRTD with doubles instead.
|
|
|
|
let Predicates = [HasNoFdivSqrtFix] in
|
2013-09-22 17:54:42 +08:00
|
|
|
def FSQRTS : F3_3u<2, 0b110100, 0b000101001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs2),
|
|
|
|
"fsqrts $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f32:$rd, (fsqrt f32:$rs2))],
|
|
|
|
IIC_fpu_sqrts>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FSQRTD : F3_3u<2, 0b110100, 0b000101010,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs2),
|
|
|
|
"fsqrtd $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f64:$rd, (fsqrt f64:$rs2))],
|
|
|
|
IIC_fpu_sqrtd>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FSQRTQ : F3_3u<2, 0b110100, 0b000101011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs2),
|
|
|
|
"fsqrtq $rs2, $rd",
|
|
|
|
[(set f128:$rd, (fsqrt f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// Floating-point Add and Subtract Instructions, p. 146
|
|
|
|
def FADDS : F3_3<2, 0b110100, 0b001000001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fadds $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f32:$rd, (fadd f32:$rs1, f32:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def FADDD : F3_3<2, 0b110100, 0b001000010,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"faddd $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f64:$rd, (fadd f64:$rs1, f64:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-08-26 02:30:06 +08:00
|
|
|
def FADDQ : F3_3<2, 0b110100, 0b001000011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs1, QFPRegs:$rs2),
|
|
|
|
"faddq $rs1, $rs2, $rd",
|
|
|
|
[(set f128:$rd, (fadd f128:$rs1, f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
def FSUBS : F3_3<2, 0b110100, 0b001000101,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fsubs $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f32:$rd, (fsub f32:$rs1, f32:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def FSUBD : F3_3<2, 0b110100, 0b001000110,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"fsubd $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f64:$rd, (fsub f64:$rs1, f64:$rs2))],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-08-26 02:30:06 +08:00
|
|
|
def FSUBQ : F3_3<2, 0b110100, 0b001000111,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs1, QFPRegs:$rs2),
|
|
|
|
"fsubq $rs1, $rs2, $rd",
|
|
|
|
[(set f128:$rd, (fsub f128:$rs1, f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Floating-point Multiply and Divide Instructions, p. 147
|
2016-06-19 19:03:28 +08:00
|
|
|
// FMULS generates an erratum on LEON processors, so by disabling this instruction
|
|
|
|
// this will be promoted to use FMULD with doubles instead.
|
|
|
|
let Predicates = [HasNoFmulsFix] in
|
2006-02-05 13:50:24 +08:00
|
|
|
def FMULS : F3_3<2, 0b110100, 0b001001001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fmuls $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f32:$rd, (fmul f32:$rs1, f32:$rs2))],
|
|
|
|
IIC_fpu_muls>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def FMULD : F3_3<2, 0b110100, 0b001001010,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"fmuld $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f64:$rd, (fmul f64:$rs1, f64:$rs2))],
|
|
|
|
IIC_fpu_muld>;
|
2013-08-26 02:30:06 +08:00
|
|
|
def FMULQ : F3_3<2, 0b110100, 0b001001011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs1, QFPRegs:$rs2),
|
|
|
|
"fmulq $rs1, $rs2, $rd",
|
|
|
|
[(set f128:$rd, (fmul f128:$rs1, f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
|
|
|
|
2016-06-19 19:03:28 +08:00
|
|
|
let Predicates = [HasNoFsmuldFix] in
|
2006-02-05 13:50:24 +08:00
|
|
|
def FSMULD : F3_3<2, 0b110100, 0b001101001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fsmuld $rs1, $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f64:$rd, (fmul (fpextend f32:$rs1),
|
|
|
|
(fpextend f32:$rs2)))],
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
IIC_fpu_muld>;
|
2013-08-26 02:30:06 +08:00
|
|
|
def FDMULQ : F3_3<2, 0b110100, 0b001101110,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"fdmulq $rs1, $rs2, $rd",
|
2016-08-19 04:08:15 +08:00
|
|
|
[(set f128:$rd, (fmul (fpextend f64:$rs1),
|
|
|
|
(fpextend f64:$rs2)))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
|
|
|
|
2016-06-19 19:03:28 +08:00
|
|
|
// FDIVS generates an erratum on LEON processors, so by disabling this instruction
|
|
|
|
// this will be promoted to use FDIVD with doubles instead.
|
2006-02-05 13:50:24 +08:00
|
|
|
def FDIVS : F3_3<2, 0b110100, 0b001001101,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs FPRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fdivs $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f32:$rd, (fdiv f32:$rs1, f32:$rs2))],
|
|
|
|
IIC_fpu_divs>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def FDIVD : F3_3<2, 0b110100, 0b001001110,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"fdivd $rs1, $rs2, $rd",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(set f64:$rd, (fdiv f64:$rs1, f64:$rs2))],
|
|
|
|
IIC_fpu_divd>;
|
2013-08-26 02:30:06 +08:00
|
|
|
def FDIVQ : F3_3<2, 0b110100, 0b001001111,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs1, QFPRegs:$rs2),
|
|
|
|
"fdivq $rs1, $rs2, $rd",
|
|
|
|
[(set f128:$rd, (fdiv f128:$rs1, f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Floating-point Compare Instructions, p. 148
|
|
|
|
// Note: the 2nd template arg is different for these guys.
|
|
|
|
// Note 2: the result of a FCMP is not available until the 2nd cycle
|
2013-10-06 15:06:44 +08:00
|
|
|
// after the instr is retired, but there is no interlock in Sparc V8.
|
|
|
|
// This behavior is modeled with a forced noop after the instruction in
|
|
|
|
// DelaySlotFiller.
|
|
|
|
|
2014-03-02 11:39:39 +08:00
|
|
|
let Defs = [FCC0], rd = 0, isCodeGenOnly = 1 in {
|
2013-09-22 17:54:42 +08:00
|
|
|
def FCMPS : F3_3c<2, 0b110101, 0b001010001,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fcmps $rs1, $rs2",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(SPcmpfcc f32:$rs1, f32:$rs2)],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FCMPD : F3_3c<2, 0b110101, 0b001010010,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"fcmpd $rs1, $rs2",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(SPcmpfcc f64:$rs1, f64:$rs2)],
|
|
|
|
IIC_fpu_fast_instr>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FCMPQ : F3_3c<2, 0b110101, 0b001010011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs), (ins QFPRegs:$rs1, QFPRegs:$rs2),
|
|
|
|
"fcmpq $rs1, $rs2",
|
|
|
|
[(SPcmpfcc f128:$rs1, f128:$rs2)]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2009-09-16 01:46:24 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2013-09-22 14:48:52 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Instructions for Thread Local Storage(TLS).
|
|
|
|
//===----------------------------------------------------------------------===//
|
2014-01-06 16:08:58 +08:00
|
|
|
let isCodeGenOnly = 1, isAsmParserOnly = 1 in {
|
2013-09-22 14:48:52 +08:00
|
|
|
def TLS_ADDrr : F3_1<2, 0b000000,
|
|
|
|
(outs IntRegs:$rd),
|
|
|
|
(ins IntRegs:$rs1, IntRegs:$rs2, TLSSym:$sym),
|
|
|
|
"add $rs1, $rs2, $rd, $sym",
|
|
|
|
[(set i32:$rd,
|
|
|
|
(tlsadd i32:$rs1, i32:$rs2, tglobaltlsaddr:$sym))]>;
|
|
|
|
|
|
|
|
let mayLoad = 1 in
|
|
|
|
def TLS_LDrr : F3_1<3, 0b000000,
|
|
|
|
(outs IntRegs:$dst), (ins MEMrr:$addr, TLSSym:$sym),
|
|
|
|
"ld [$addr], $dst, $sym",
|
|
|
|
[(set i32:$dst,
|
|
|
|
(tlsld ADDRrr:$addr, tglobaltlsaddr:$sym))]>;
|
|
|
|
|
2013-10-08 10:50:29 +08:00
|
|
|
let Uses = [O6], isCall = 1, hasDelaySlot = 1 in
|
2013-09-22 14:48:52 +08:00
|
|
|
def TLS_CALL : InstSP<(outs),
|
|
|
|
(ins calltarget:$disp, TLSSym:$sym, variable_ops),
|
2013-10-08 10:50:29 +08:00
|
|
|
"call $disp, $sym",
|
[Sparc] This provides support for itineraries on Sparc.
Specifically, itineraries for LEON processors has been added, along with several LEON processor Subtargets. Although currently all these targets are pretty much identical, support for features that will differ among these processors will be added in the very near future.
The different Instruction Itinerary Classes (IICs) added are sufficient to differentiate between the instruction timings used by LEON and, quite probably, by generic Sparc processors too, but the focus of the exercise has been for LEON processors, as the requirement of my project. If the IICs are not sufficient for other Sparc processor types and you want to add a new itinerary for one of those, it should be relatively trivial to adapt this.
As none of the LEON processors has Quad Floats, or is a Version 9 processor, none of those instructions have itinerary classes defined and revert to the default "NoItinerary" instruction itinerary.
Phabricator Review: http://reviews.llvm.org/D19359
llvm-svn: 267121
2016-04-22 16:17:17 +08:00
|
|
|
[(tlscall texternalsym:$disp, tglobaltlsaddr:$sym)],
|
|
|
|
IIC_jmp_or_call> {
|
2013-09-22 14:48:52 +08:00
|
|
|
bits<30> disp;
|
|
|
|
let op = 1;
|
|
|
|
let Inst{29-0} = disp;
|
|
|
|
}
|
2014-01-06 16:08:58 +08:00
|
|
|
}
|
2013-09-22 14:48:52 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// V9 Instructions
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
// V9 Conditional Moves.
|
2013-05-20 04:20:54 +08:00
|
|
|
let Predicates = [HasV9], Constraints = "$f = $rd" in {
|
2006-02-05 13:50:24 +08:00
|
|
|
// Move Integer Register on Condition (MOVcc) p. 194 of the V9 manual.
|
2014-03-02 12:43:45 +08:00
|
|
|
let Uses = [ICC], intcc = 1, cc = 0b00 in {
|
2011-01-22 19:36:24 +08:00
|
|
|
def MOVICCrr
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_1<0b101100, (outs IntRegs:$rd),
|
|
|
|
(ins IntRegs:$rs2, IntRegs:$f, CCOp:$cond),
|
|
|
|
"mov$cond %icc, $rs2, $rd",
|
|
|
|
[(set i32:$rd, (SPselecticc i32:$rs2, i32:$f, imm:$cond))]>;
|
|
|
|
|
2011-01-22 19:36:24 +08:00
|
|
|
def MOVICCri
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_2<0b101100, (outs IntRegs:$rd),
|
|
|
|
(ins i32imm:$simm11, IntRegs:$f, CCOp:$cond),
|
|
|
|
"mov$cond %icc, $simm11, $rd",
|
|
|
|
[(set i32:$rd,
|
|
|
|
(SPselecticc simm11:$simm11, i32:$f, imm:$cond))]>;
|
2011-01-22 19:36:24 +08:00
|
|
|
}
|
|
|
|
|
2014-03-02 12:43:45 +08:00
|
|
|
let Uses = [FCC0], intcc = 0, cc = 0b00 in {
|
2011-01-22 19:36:24 +08:00
|
|
|
def MOVFCCrr
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_1<0b101100, (outs IntRegs:$rd),
|
|
|
|
(ins IntRegs:$rs2, IntRegs:$f, CCOp:$cond),
|
|
|
|
"mov$cond %fcc0, $rs2, $rd",
|
|
|
|
[(set i32:$rd, (SPselectfcc i32:$rs2, i32:$f, imm:$cond))]>;
|
2011-01-22 19:36:24 +08:00
|
|
|
def MOVFCCri
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_2<0b101100, (outs IntRegs:$rd),
|
|
|
|
(ins i32imm:$simm11, IntRegs:$f, CCOp:$cond),
|
|
|
|
"mov$cond %fcc0, $simm11, $rd",
|
|
|
|
[(set i32:$rd,
|
|
|
|
(SPselectfcc simm11:$simm11, i32:$f, imm:$cond))]>;
|
2011-01-22 19:36:24 +08:00
|
|
|
}
|
|
|
|
|
2014-03-02 12:43:45 +08:00
|
|
|
let Uses = [ICC], intcc = 1, opf_cc = 0b00 in {
|
2011-01-22 19:36:24 +08:00
|
|
|
def FMOVS_ICC
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_3<0b110101, 0b000001, (outs FPRegs:$rd),
|
|
|
|
(ins FPRegs:$rs2, FPRegs:$f, CCOp:$cond),
|
|
|
|
"fmovs$cond %icc, $rs2, $rd",
|
|
|
|
[(set f32:$rd, (SPselecticc f32:$rs2, f32:$f, imm:$cond))]>;
|
2011-01-22 19:36:24 +08:00
|
|
|
def FMOVD_ICC
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_3<0b110101, 0b000010, (outs DFPRegs:$rd),
|
|
|
|
(ins DFPRegs:$rs2, DFPRegs:$f, CCOp:$cond),
|
|
|
|
"fmovd$cond %icc, $rs2, $rd",
|
|
|
|
[(set f64:$rd, (SPselecticc f64:$rs2, f64:$f, imm:$cond))]>;
|
|
|
|
def FMOVQ_ICC
|
|
|
|
: F4_3<0b110101, 0b000011, (outs QFPRegs:$rd),
|
|
|
|
(ins QFPRegs:$rs2, QFPRegs:$f, CCOp:$cond),
|
2014-01-08 14:14:52 +08:00
|
|
|
"fmovq$cond %icc, $rs2, $rd",
|
|
|
|
[(set f128:$rd, (SPselecticc f128:$rs2, f128:$f, imm:$cond))]>,
|
|
|
|
Requires<[HasHardQuad]>;
|
2011-01-22 19:36:24 +08:00
|
|
|
}
|
|
|
|
|
2014-03-02 12:43:45 +08:00
|
|
|
let Uses = [FCC0], intcc = 0, opf_cc = 0b00 in {
|
2011-01-22 19:36:24 +08:00
|
|
|
def FMOVS_FCC
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_3<0b110101, 0b000001, (outs FPRegs:$rd),
|
|
|
|
(ins FPRegs:$rs2, FPRegs:$f, CCOp:$cond),
|
|
|
|
"fmovs$cond %fcc0, $rs2, $rd",
|
|
|
|
[(set f32:$rd, (SPselectfcc f32:$rs2, f32:$f, imm:$cond))]>;
|
2011-01-22 19:36:24 +08:00
|
|
|
def FMOVD_FCC
|
2013-09-22 17:18:26 +08:00
|
|
|
: F4_3<0b110101, 0b000010, (outs DFPRegs:$rd),
|
|
|
|
(ins DFPRegs:$rs2, DFPRegs:$f, CCOp:$cond),
|
|
|
|
"fmovd$cond %fcc0, $rs2, $rd",
|
|
|
|
[(set f64:$rd, (SPselectfcc f64:$rs2, f64:$f, imm:$cond))]>;
|
|
|
|
def FMOVQ_FCC
|
|
|
|
: F4_3<0b110101, 0b000011, (outs QFPRegs:$rd),
|
|
|
|
(ins QFPRegs:$rs2, QFPRegs:$f, CCOp:$cond),
|
2014-01-08 14:14:52 +08:00
|
|
|
"fmovq$cond %fcc0, $rs2, $rd",
|
|
|
|
[(set f128:$rd, (SPselectfcc f128:$rs2, f128:$f, imm:$cond))]>,
|
|
|
|
Requires<[HasHardQuad]>;
|
2011-01-22 19:36:24 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
// Floating-Point Move Instructions, p. 164 of the V9 manual.
|
|
|
|
let Predicates = [HasV9] in {
|
2013-09-22 17:54:42 +08:00
|
|
|
def FMOVD : F3_3u<2, 0b110100, 0b000000010,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs2),
|
|
|
|
"fmovd $rs2, $rd", []>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FMOVQ : F3_3u<2, 0b110100, 0b000000011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs2),
|
|
|
|
"fmovq $rs2, $rd", []>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FNEGD : F3_3u<2, 0b110100, 0b000000110,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs2),
|
|
|
|
"fnegd $rs2, $rd",
|
|
|
|
[(set f64:$rd, (fneg f64:$rs2))]>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FNEGQ : F3_3u<2, 0b110100, 0b000000111,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs2),
|
|
|
|
"fnegq $rs2, $rd",
|
|
|
|
[(set f128:$rd, (fneg f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FABSD : F3_3u<2, 0b110100, 0b000001010,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs DFPRegs:$rd), (ins DFPRegs:$rs2),
|
|
|
|
"fabsd $rs2, $rd",
|
|
|
|
[(set f64:$rd, (fabs f64:$rs2))]>;
|
2013-09-22 17:54:42 +08:00
|
|
|
def FABSQ : F3_3u<2, 0b110100, 0b000001011,
|
2014-01-12 12:48:54 +08:00
|
|
|
(outs QFPRegs:$rd), (ins QFPRegs:$rs2),
|
|
|
|
"fabsq $rs2, $rd",
|
|
|
|
[(set f128:$rd, (fabs f128:$rs2))]>,
|
2013-08-26 02:30:06 +08:00
|
|
|
Requires<[HasHardQuad]>;
|
2006-02-05 13:50:24 +08:00
|
|
|
}
|
|
|
|
|
2014-03-02 14:28:15 +08:00
|
|
|
// Floating-point compare instruction with %fcc0-%fcc3.
|
2014-03-02 11:39:39 +08:00
|
|
|
def V9FCMPS : F3_3c<2, 0b110101, 0b001010001,
|
|
|
|
(outs FCCRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fcmps $rd, $rs1, $rs2", []>;
|
|
|
|
def V9FCMPD : F3_3c<2, 0b110101, 0b001010010,
|
|
|
|
(outs FCCRegs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"fcmpd $rd, $rs1, $rs2", []>;
|
|
|
|
def V9FCMPQ : F3_3c<2, 0b110101, 0b001010011,
|
|
|
|
(outs FCCRegs:$rd), (ins QFPRegs:$rs1, QFPRegs:$rs2),
|
|
|
|
"fcmpq $rd, $rs1, $rs2", []>,
|
|
|
|
Requires<[HasHardQuad]>;
|
|
|
|
|
2014-03-03 03:56:19 +08:00
|
|
|
let hasSideEffects = 1 in {
|
|
|
|
def V9FCMPES : F3_3c<2, 0b110101, 0b001010101,
|
|
|
|
(outs FCCRegs:$rd), (ins FPRegs:$rs1, FPRegs:$rs2),
|
|
|
|
"fcmpes $rd, $rs1, $rs2", []>;
|
|
|
|
def V9FCMPED : F3_3c<2, 0b110101, 0b001010110,
|
|
|
|
(outs FCCRegs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
|
|
|
|
"fcmped $rd, $rs1, $rs2", []>;
|
|
|
|
def V9FCMPEQ : F3_3c<2, 0b110101, 0b001010111,
|
|
|
|
(outs FCCRegs:$rd), (ins QFPRegs:$rs1, QFPRegs:$rs2),
|
|
|
|
"fcmpeq $rd, $rs1, $rs2", []>,
|
|
|
|
Requires<[HasHardQuad]>;
|
|
|
|
}
|
|
|
|
|
2014-03-02 14:28:15 +08:00
|
|
|
// Floating point conditional move instrucitons with %fcc0-%fcc3.
|
|
|
|
let Predicates = [HasV9] in {
|
|
|
|
let Constraints = "$f = $rd", intcc = 0 in {
|
|
|
|
def V9MOVFCCrr
|
|
|
|
: F4_1<0b101100, (outs IntRegs:$rd),
|
|
|
|
(ins FCCRegs:$cc, IntRegs:$rs2, IntRegs:$f, CCOp:$cond),
|
|
|
|
"mov$cond $cc, $rs2, $rd", []>;
|
|
|
|
def V9MOVFCCri
|
|
|
|
: F4_2<0b101100, (outs IntRegs:$rd),
|
|
|
|
(ins FCCRegs:$cc, i32imm:$simm11, IntRegs:$f, CCOp:$cond),
|
|
|
|
"mov$cond $cc, $simm11, $rd", []>;
|
|
|
|
def V9FMOVS_FCC
|
|
|
|
: F4_3<0b110101, 0b000001, (outs FPRegs:$rd),
|
|
|
|
(ins FCCRegs:$opf_cc, FPRegs:$rs2, FPRegs:$f, CCOp:$cond),
|
|
|
|
"fmovs$cond $opf_cc, $rs2, $rd", []>;
|
|
|
|
def V9FMOVD_FCC
|
|
|
|
: F4_3<0b110101, 0b000010, (outs DFPRegs:$rd),
|
|
|
|
(ins FCCRegs:$opf_cc, DFPRegs:$rs2, DFPRegs:$f, CCOp:$cond),
|
|
|
|
"fmovd$cond $opf_cc, $rs2, $rd", []>;
|
|
|
|
def V9FMOVQ_FCC
|
|
|
|
: F4_3<0b110101, 0b000011, (outs QFPRegs:$rd),
|
|
|
|
(ins FCCRegs:$opf_cc, QFPRegs:$rs2, QFPRegs:$f, CCOp:$cond),
|
|
|
|
"fmovq$cond $opf_cc, $rs2, $rd", []>,
|
|
|
|
Requires<[HasHardQuad]>;
|
|
|
|
} // Constraints = "$f = $rd", ...
|
|
|
|
} // let Predicates = [hasV9]
|
|
|
|
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// POPCrr - This does a ctpop of a 64-bit register. As such, we have to clear
|
2014-01-02 03:00:10 +08:00
|
|
|
// the top 32-bits before using it. To do this clearing, we use a SRLri X,0.
|
2013-09-22 17:54:42 +08:00
|
|
|
let rs1 = 0 in
|
|
|
|
def POPCrr : F3_1<2, 0b101110,
|
2015-08-06 01:00:30 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs2),
|
|
|
|
"popc $rs2, $rd", []>, Requires<[HasV9]>;
|
2013-03-24 04:35:05 +08:00
|
|
|
def : Pat<(ctpop i32:$src),
|
2014-01-02 03:00:10 +08:00
|
|
|
(POPCrr (SRLri $src, 0))>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2014-01-02 06:11:54 +08:00
|
|
|
let Predicates = [HasV9], hasSideEffects = 1, rd = 0, rs1 = 0b01111 in
|
2014-03-01 17:11:57 +08:00
|
|
|
def MEMBARi : F3_2<2, 0b101000, (outs), (ins simm13Op:$simm13),
|
2014-01-02 06:11:54 +08:00
|
|
|
"membar $simm13", []>;
|
|
|
|
|
2016-05-16 19:02:00 +08:00
|
|
|
// The CAS instruction, unlike other instructions, only comes in a
|
|
|
|
// form which requires an ASI be provided. The ASI value hardcoded
|
|
|
|
// here is ASI_PRIMARY, the default unprivileged ASI for SparcV9.
|
Sparc: Add the "alternate address space" load/store instructions.
- Adds support for the asm syntax, which has an immediate integer
"ASI" (address space identifier) appearing after an address, before
a comma.
- Adds the various-width load, store, and swap in alternate address
space instructions. (ldsba, ldsha, lduba, lduha, lda, stba, stha,
sta, swapa)
This does not attempt to hook these instructions up to pointer address
spaces in LLVM, although that would probably be a reasonable thing to
do in the future.
Differential Revision: http://reviews.llvm.org/D8904
llvm-svn: 237581
2015-05-19 00:35:04 +08:00
|
|
|
let Predicates = [HasV9], Constraints = "$swap = $rd", asi = 0b10000000 in
|
|
|
|
def CASrr: F3_1_asi<3, 0b111100,
|
2014-01-02 06:11:54 +08:00
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2,
|
|
|
|
IntRegs:$swap),
|
|
|
|
"cas [$rs1], $rs2, $rd",
|
|
|
|
[(set i32:$rd,
|
2016-05-24 04:33:00 +08:00
|
|
|
(atomic_cmp_swap_32 iPTR:$rs1, i32:$rs2, i32:$swap))]>;
|
2014-01-02 06:11:54 +08:00
|
|
|
|
2016-05-16 19:02:00 +08:00
|
|
|
|
|
|
|
// CASA is supported as an instruction on some LEON3 and all LEON4 processors.
|
|
|
|
// This version can be automatically lowered from C code, selecting ASI 10
|
|
|
|
let Predicates = [HasLeonCASA], Constraints = "$swap = $rd", asi = 0b00001010 in
|
|
|
|
def CASAasi10: F3_1_asi<3, 0b111100,
|
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2,
|
|
|
|
IntRegs:$swap),
|
|
|
|
"casa [$rs1] 10, $rs2, $rd",
|
|
|
|
[(set i32:$rd,
|
2016-05-24 04:33:00 +08:00
|
|
|
(atomic_cmp_swap_32 iPTR:$rs1, i32:$rs2, i32:$swap))]>;
|
2016-05-16 19:02:00 +08:00
|
|
|
|
|
|
|
// CASA supported on some LEON3 and all LEON4 processors. Same pattern as
|
|
|
|
// CASrr, above, but with a different ASI. This version is supported for
|
|
|
|
// inline assembly lowering only.
|
|
|
|
let Predicates = [HasLeonCASA], Constraints = "$swap = $rd" in
|
|
|
|
def CASArr: F3_1_asi<3, 0b111100,
|
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2,
|
|
|
|
IntRegs:$swap, i8imm:$asi),
|
|
|
|
"casa [$rs1] $asi, $rs2, $rd", []>;
|
|
|
|
|
2016-05-09 19:55:15 +08:00
|
|
|
// TODO: Add DAG sequence to lower these instructions. Currently, only provided
|
|
|
|
// as inline assembler-supported instructions.
|
|
|
|
let Predicates = [HasUMAC_SMAC], Defs = [Y, ASR18], Uses = [Y, ASR18] in {
|
|
|
|
def SMACrr : F3_1<2, 0b111111,
|
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2, ASRRegs:$asr18),
|
|
|
|
"smac $rs1, $rs2, $rd",
|
|
|
|
[], IIC_smac_umac>;
|
|
|
|
|
|
|
|
def SMACri : F3_2<2, 0b111111,
|
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13, ASRRegs:$asr18),
|
|
|
|
"smac $rs1, $simm13, $rd",
|
|
|
|
[], IIC_smac_umac>;
|
|
|
|
|
|
|
|
def UMACrr : F3_1<2, 0b111110,
|
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2, ASRRegs:$asr18),
|
|
|
|
"umac $rs1, $rs2, $rd",
|
|
|
|
[], IIC_smac_umac>;
|
|
|
|
|
|
|
|
def UMACri : F3_2<2, 0b111110,
|
|
|
|
(outs IntRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13, ASRRegs:$asr18),
|
|
|
|
"umac $rs1, $simm13, $rd",
|
|
|
|
[], IIC_smac_umac>;
|
|
|
|
}
|
|
|
|
|
2014-03-02 01:51:00 +08:00
|
|
|
let Defs = [ICC] in {
|
|
|
|
defm TADDCC : F3_12np<"taddcc", 0b100000>;
|
|
|
|
defm TSUBCC : F3_12np<"tsubcc", 0b100001>;
|
|
|
|
|
|
|
|
let hasSideEffects = 1 in {
|
|
|
|
defm TADDCCTV : F3_12np<"taddcctv", 0b100010>;
|
|
|
|
defm TSUBCCTV : F3_12np<"tsubcctv", 0b100011>;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-04 17:11:22 +08:00
|
|
|
|
|
|
|
// Section A.43 - Read Privileged Register Instructions
|
|
|
|
let Predicates = [HasV9] in {
|
|
|
|
let rs2 = 0 in
|
|
|
|
def RDPR : F3_1<2, 0b101010,
|
|
|
|
(outs IntRegs:$rd), (ins PRRegs:$rs1),
|
|
|
|
"rdpr $rs1, $rd", []>;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Section A.62 - Write Privileged Register Instructions
|
|
|
|
let Predicates = [HasV9] in {
|
|
|
|
def WRPRrr : F3_1<2, 0b110010,
|
|
|
|
(outs PRRegs:$rd), (ins IntRegs:$rs1, IntRegs:$rs2),
|
|
|
|
"wrpr $rs1, $rs2, $rd", []>;
|
|
|
|
def WRPRri : F3_2<2, 0b110010,
|
|
|
|
(outs PRRegs:$rd), (ins IntRegs:$rs1, simm13Op:$simm13),
|
|
|
|
"wrpr $rs1, $simm13, $rd", []>;
|
|
|
|
}
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Non-Instruction Patterns
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
// Small immediates.
|
|
|
|
def : Pat<(i32 simm13:$val),
|
2013-04-02 12:08:54 +08:00
|
|
|
(ORri (i32 G0), imm:$val)>;
|
2006-02-05 13:50:24 +08:00
|
|
|
// Arbitrary immediates.
|
|
|
|
def : Pat<(i32 imm:$val),
|
|
|
|
(ORri (SETHIi (HI22 imm:$val)), (LO10 imm:$val))>;
|
|
|
|
|
2006-02-17 13:43:56 +08:00
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Global addresses, constant pool entries
|
2013-12-29 15:15:09 +08:00
|
|
|
let Predicates = [Is32Bit] in {
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
def : Pat<(SPhi tglobaladdr:$in), (SETHIi tglobaladdr:$in)>;
|
2013-04-02 12:08:54 +08:00
|
|
|
def : Pat<(SPlo tglobaladdr:$in), (ORri (i32 G0), tglobaladdr:$in)>;
|
2006-02-05 13:50:24 +08:00
|
|
|
def : Pat<(SPhi tconstpool:$in), (SETHIi tconstpool:$in)>;
|
2013-04-02 12:08:54 +08:00
|
|
|
def : Pat<(SPlo tconstpool:$in), (ORri (i32 G0), tconstpool:$in)>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2013-09-22 14:48:52 +08:00
|
|
|
// GlobalTLS addresses
|
|
|
|
def : Pat<(SPhi tglobaltlsaddr:$in), (SETHIi tglobaltlsaddr:$in)>;
|
|
|
|
def : Pat<(SPlo tglobaltlsaddr:$in), (ORri (i32 G0), tglobaltlsaddr:$in)>;
|
|
|
|
def : Pat<(add (SPhi tglobaltlsaddr:$in1), (SPlo tglobaltlsaddr:$in2)),
|
|
|
|
(ADDri (SETHIi tglobaltlsaddr:$in1), (tglobaltlsaddr:$in2))>;
|
|
|
|
def : Pat<(xor (SPhi tglobaltlsaddr:$in1), (SPlo tglobaltlsaddr:$in2)),
|
|
|
|
(XORri (SETHIi tglobaltlsaddr:$in1), (tglobaltlsaddr:$in2))>;
|
|
|
|
|
2013-06-03 13:58:33 +08:00
|
|
|
// Blockaddress
|
|
|
|
def : Pat<(SPhi tblockaddress:$in), (SETHIi tblockaddress:$in)>;
|
|
|
|
def : Pat<(SPlo tblockaddress:$in), (ORri (i32 G0), tblockaddress:$in)>;
|
|
|
|
|
2006-02-05 13:50:24 +08:00
|
|
|
// Add reg, lo. This is used when taking the addr of a global/constpool entry.
|
2013-04-14 09:53:23 +08:00
|
|
|
def : Pat<(add iPTR:$r, (SPlo tglobaladdr:$in)), (ADDri $r, tglobaladdr:$in)>;
|
|
|
|
def : Pat<(add iPTR:$r, (SPlo tconstpool:$in)), (ADDri $r, tconstpool:$in)>;
|
2013-06-03 13:58:33 +08:00
|
|
|
def : Pat<(add iPTR:$r, (SPlo tblockaddress:$in)),
|
|
|
|
(ADDri $r, tblockaddress:$in)>;
|
2013-12-29 15:15:09 +08:00
|
|
|
}
|
2006-02-05 13:50:24 +08:00
|
|
|
|
2013-06-05 02:33:25 +08:00
|
|
|
// Calls:
|
2006-02-05 13:50:24 +08:00
|
|
|
def : Pat<(call tglobaladdr:$dst),
|
|
|
|
(CALL tglobaladdr:$dst)>;
|
2006-02-10 15:35:42 +08:00
|
|
|
def : Pat<(call texternalsym:$dst),
|
|
|
|
(CALL texternalsym:$dst)>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// Map integer extload's to zextloads.
|
2006-10-10 04:57:25 +08:00
|
|
|
def : Pat<(i32 (extloadi1 ADDRrr:$src)), (LDUBrr ADDRrr:$src)>;
|
|
|
|
def : Pat<(i32 (extloadi1 ADDRri:$src)), (LDUBri ADDRri:$src)>;
|
|
|
|
def : Pat<(i32 (extloadi8 ADDRrr:$src)), (LDUBrr ADDRrr:$src)>;
|
|
|
|
def : Pat<(i32 (extloadi8 ADDRri:$src)), (LDUBri ADDRri:$src)>;
|
|
|
|
def : Pat<(i32 (extloadi16 ADDRrr:$src)), (LDUHrr ADDRrr:$src)>;
|
|
|
|
def : Pat<(i32 (extloadi16 ADDRri:$src)), (LDUHri ADDRri:$src)>;
|
2006-02-05 13:50:24 +08:00
|
|
|
|
|
|
|
// zextload bool -> zextload byte
|
2006-10-10 04:57:25 +08:00
|
|
|
def : Pat<(i32 (zextloadi1 ADDRrr:$src)), (LDUBrr ADDRrr:$src)>;
|
|
|
|
def : Pat<(i32 (zextloadi1 ADDRri:$src)), (LDUBri ADDRri:$src)>;
|
2013-04-02 12:09:12 +08:00
|
|
|
|
2013-06-03 08:21:54 +08:00
|
|
|
// store 0, addr -> store %g0, addr
|
|
|
|
def : Pat<(store (i32 0), ADDRrr:$dst), (STrr ADDRrr:$dst, (i32 G0))>;
|
|
|
|
def : Pat<(store (i32 0), ADDRri:$dst), (STri ADDRri:$dst, (i32 G0))>;
|
|
|
|
|
2014-01-02 06:11:54 +08:00
|
|
|
// store bar for all atomic_fence in V8.
|
|
|
|
let Predicates = [HasNoV9] in
|
|
|
|
def : Pat<(atomic_fence imm, imm), (STBAR)>;
|
|
|
|
|
2016-05-24 04:33:00 +08:00
|
|
|
// atomic_load addr -> load addr
|
|
|
|
def : Pat<(i32 (atomic_load_8 ADDRrr:$src)), (LDUBrr ADDRrr:$src)>;
|
|
|
|
def : Pat<(i32 (atomic_load_8 ADDRri:$src)), (LDUBri ADDRri:$src)>;
|
|
|
|
def : Pat<(i32 (atomic_load_16 ADDRrr:$src)), (LDUHrr ADDRrr:$src)>;
|
|
|
|
def : Pat<(i32 (atomic_load_16 ADDRri:$src)), (LDUHri ADDRri:$src)>;
|
|
|
|
def : Pat<(i32 (atomic_load_32 ADDRrr:$src)), (LDrr ADDRrr:$src)>;
|
|
|
|
def : Pat<(i32 (atomic_load_32 ADDRri:$src)), (LDri ADDRri:$src)>;
|
|
|
|
|
|
|
|
// atomic_store val, addr -> store val, addr
|
|
|
|
def : Pat<(atomic_store_8 ADDRrr:$dst, i32:$val), (STBrr ADDRrr:$dst, $val)>;
|
|
|
|
def : Pat<(atomic_store_8 ADDRri:$dst, i32:$val), (STBri ADDRri:$dst, $val)>;
|
|
|
|
def : Pat<(atomic_store_16 ADDRrr:$dst, i32:$val), (STHrr ADDRrr:$dst, $val)>;
|
|
|
|
def : Pat<(atomic_store_16 ADDRri:$dst, i32:$val), (STHri ADDRri:$dst, $val)>;
|
|
|
|
def : Pat<(atomic_store_32 ADDRrr:$dst, i32:$val), (STrr ADDRrr:$dst, $val)>;
|
|
|
|
def : Pat<(atomic_store_32 ADDRri:$dst, i32:$val), (STri ADDRri:$dst, $val)>;
|
2014-01-02 06:11:54 +08:00
|
|
|
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
// extract_vector
|
2015-12-12 03:20:16 +08:00
|
|
|
def : Pat<(extractelt (v2i32 IntPair:$Rn), 0),
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
(i32 (EXTRACT_SUBREG IntPair:$Rn, sub_even))>;
|
2015-12-12 03:20:16 +08:00
|
|
|
def : Pat<(extractelt (v2i32 IntPair:$Rn), 1),
|
[Sparc] Implement i64 load/store support for 32-bit sparc.
The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).
As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.
The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.
This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.
- Modifies the list of reserved registers, the stack spilling code,
and register copying code to support the IntPair register class.
- Adds support in AsmParser. (note that in asm text, you write the
name of the first register of the pair only. So the parser has to
morph the single register into the equivalent paired register).
- Adds the new instructions themselves (LDD/STD/LDDA/STDA).
- Hooks up the instructions and registers as a vector type v2i32. Adds
custom legalizer to transform i64 load/stores into v2i32 load/stores
and bitcasts, so that the new instructions can actually be
generated, and marks all operations other than load/store on v2i32
as needing to be expanded.
- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
This hack undoes the transformation of i64 operands into two
arbitrarily-allocated separate i32 registers in
SelectionDAGBuilder. and instead passes them in a single
IntPair. (Arbitrarily allocated registers are not useful, asm code
expects to be receiving a pair, which can be passed to ldd/std.)
Also adds a bunch of test cases covering all the bugs I've added along
the way.
Differential Revision: http://reviews.llvm.org/D8713
llvm-svn: 244484
2015-08-11 03:11:39 +08:00
|
|
|
(i32 (EXTRACT_SUBREG IntPair:$Rn, sub_odd))>;
|
|
|
|
|
|
|
|
// build_vector
|
|
|
|
def : Pat<(build_vector (i32 IntRegs:$a1), (i32 IntRegs:$a2)),
|
|
|
|
(INSERT_SUBREG
|
|
|
|
(INSERT_SUBREG (v2i32 (IMPLICIT_DEF)), (i32 IntRegs:$a1), sub_even),
|
|
|
|
(i32 IntRegs:$a2), sub_odd)>;
|
|
|
|
|
2014-01-02 06:11:54 +08:00
|
|
|
|
2013-04-02 12:09:12 +08:00
|
|
|
include "SparcInstr64Bit.td"
|
2014-03-03 03:31:21 +08:00
|
|
|
include "SparcInstrVIS.td"
|
2014-01-08 14:14:52 +08:00
|
|
|
include "SparcInstrAliases.td"
|