+<p>The Instruction class (defined in <tt>Target.td</tt>) is mostly used as a
+base for more complex instruction classes.</p>
+</div>
+
+<div class="doc_code">
+<pre>class Instruction {
+ string Namespace = "";
+ dag OutOperandList; // An dag containing the MI def operand list.
+ dag InOperandList; // An dag containing the MI use operand list.
+ string AsmString = ""; // The .s format to print the instruction with.
+ list<dag> Pattern; // Set to the DAG pattern for this instruction
+ list<Register> Uses = [];
+ list<Register> Defs = [];
+ list<Predicate> Predicates = []; // predicates turned into isel match code
+ ... remainder not shown for space ...
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>A SelectionDAG node (SDNode) should contain an object
+representing a target-specific instruction that is defined in <tt>XXXInstrInfo.td</tt>. The
+instruction objects should represent instructions from the architecture manual
+of the target machine (such as the
+SPARC Architecture Manual for the SPARC target). </p>
+
+<p>A single
+instruction from the architecture manual is often modeled as multiple target
+instructions, depending upon its operands. For example, a manual might
+describe an add instruction that takes a register or an immediate operand. An
+LLVM target could model this with two instructions named ADDri and ADDrr.</p>
+
+<p>You should define a
+class for each instruction category and define each opcode as a subclass of the
+category with appropriate parameters such as the fixed binary encoding of
+opcodes and extended opcodes. You should map the register bits to the bits of
+the instruction in which they are encoded (for the JIT). Also you should specify
+how the instruction should be printed when the automatic assembly printer is
+used.</p>
+
+<p>As is described in
+the SPARC Architecture Manual, Version 8, there are three major 32-bit formats
+for instructions. Format 1 is only for the CALL instruction. Format 2 is for
+branch on condition codes and SETHI (set high bits of a register) instructions.
+Format 3 is for other instructions. </p>
+
+<p>Each of these
+formats has corresponding classes in <tt>SparcInstrFormat.td</tt>. InstSP is a base
+class for other instruction classes. Additional base classes are specified for
+more precise formats: for example in <tt>SparcInstrFormat.td</tt>, F2_1 is for SETHI,
+and F2_2 is for branches. There are three other base classes: F3_1 for
+register/register operations, F3_2 for register/immediate operations, and F3_3 for
+floating-point operations. <tt>SparcInstrInfo.td</tt> also adds the base class Pseudo for
+synthetic SPARC instructions. </p>
+
+<p><tt>SparcInstrInfo.td</tt>
+largely consists of operand and instruction definitions for the SPARC target. In
+<tt>SparcInstrInfo.td</tt>, the following target description file entry, LDrr, defines
+the Load Integer instruction for a Word (the LD SPARC opcode) from a memory
+address to a register. The first parameter, the value 3 (11<sub>2</sub>), is
+the operation value for this category of operation. The second parameter
+(000000<sub>2</sub>) is the specific operation value for LD/Load Word. The
+third parameter is the output destination, which is a register operand and
+defined in the Register target description file (IntRegs). </p>
+</div>
+<div class="doc_code">
+<pre>def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
+ "ld [$addr], $dst",
+ [(set IntRegs:$dst, (load ADDRrr:$addr))]>;
+</pre>
+</div>
+
+<div class="doc_text">
+<p>The fourth
+parameter is the input source, which uses the address operand MEMrr that is
+defined earlier in <tt>SparcInstrInfo.td</tt>:</p>
+</div>
+<div class="doc_code">
+<pre>def MEMrr : Operand<i32> {
+ let PrintMethod = "printMemOperand";
+ let MIOperandInfo = (ops IntRegs, IntRegs);
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>The fifth parameter is a string that is used by the assembly
+printer and can be left as an empty string until the assembly printer interface
+is implemented. The sixth and final parameter is the pattern used to match the
+instruction during the SelectionDAG Select Phase described in
+(<a href="http://www.llvm.org/docs/CodeGenerator.html">The LLVM Target-Independent Code Generator</a>).
+This parameter is detailed in the next section, <a href="#InstructionSelector">Instruction Selector</a>.</p>
+
+<p>Instruction class definitions are not overloaded for different
+operand types, so separate versions of instructions are needed for register,
+memory, or immediate value operands. For example, to perform a
+Load Integer instruction for a Word
+from an immediate operand to a register, the following instruction class is
+defined: </p>
+</div>
+<div class="doc_code">
+<pre>def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
+ "ld [$addr], $dst",
+ [(set IntRegs:$dst, (load ADDRri:$addr))]>;
+</pre>
+</div>
+<div class="doc_text">
+<p>Writing these definitions for so many similar instructions can
+involve a lot of cut and paste. In td files, the <tt>multiclass</tt> directive enables
+the creation of templates to define several instruction classes at once (using
+the <tt>defm</tt> directive). For example in
+<tt>SparcInstrInfo.td</tt>, the <tt>multiclass</tt> pattern F3_12 is defined to create 2
+instruction classes each time F3_12 is invoked: </p>
+</div>
+<div class="doc_code">
+<pre>multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
+ def rr : F3_1 <2, Op3Val,
+ (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
+ !strconcat(OpcStr, " $b, $c, $dst"),
+ [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>;
+ def ri : F3_2 <2, Op3Val,
+ (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
+ !strconcat(OpcStr, " $b, $c, $dst"),
+ [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>;
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>So when the <tt>defm</tt> directive is used for the XOR and ADD
+instructions, as seen below, it creates four instruction objects: XORrr, XORri,
+ADDrr, and ADDri.</p>
+</div>
+<div class="doc_code">
+<pre>defm XOR : F3_12<"xor", 0b000011, xor>;
+defm ADD : F3_12<"add", 0b000000, add>;
+</pre>
+</div>
+
+<div class="doc_text">
+<p><tt>SparcInstrInfo.td</tt>
+also includes definitions for condition codes that are referenced by branch
+instructions. The following definitions in <tt>SparcInstrInfo.td</tt> indicate the bit location
+of the SPARC condition code; for example, the 10<sup>th</sup> bit represents
+the ‘greater than’ condition for integers, and the 22<sup>nd</sup> bit
+represents the ‘greater than’ condition for floats. </p>
+</div>
+
+<div class="doc_code">
+<pre>def ICC_NE : ICC_VAL< 9>; // Not Equal
+def ICC_E : ICC_VAL< 1>; // Equal
+def ICC_G : ICC_VAL<10>; // Greater
+...
+def FCC_U : FCC_VAL<23>; // Unordered
+def FCC_G : FCC_VAL<22>; // Greater
+def FCC_UG : FCC_VAL<21>; // Unordered or Greater
+...
+</pre>
+</div>
+
+<div class="doc_text">
+<p>(Note that <tt>Sparc.h</tt>
+also defines enums that correspond to the same SPARC condition codes. Care must
+be taken to ensure the values in <tt>Sparc.h</tt> correspond to the values in
+<tt>SparcInstrInfo.td</tt>; that is, <tt>SPCC::ICC_NE = 9</tt>, <tt>SPCC::FCC_U = 23</tt> and so on.)</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="implementInstr">Implement a subclass of
+ <a href="http://www.llvm.org/docs/CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a></a>
+</div>
+
+<div class="doc_text">
+<p>The final step is to hand code portions of XXXInstrInfo, which
+implements the interface described in <tt>TargetInstrInfo.h</tt>. These functions return
+0 or a Boolean or they assert, unless overridden. Here's a list of functions
+that are overridden for the SPARC implementation in <tt>SparcInstrInfo.cpp</tt>:</p>
+<ul>
+<li><tt>isMoveInstr</tt> (return true if the instruction is a register to
+register move; false, otherwise)</li>
+
+<li><tt>isLoadFromStackSlot</tt> (if the specified machine instruction is a
+direct load from a stack slot, return the register number of the destination
+and the FrameIndex of the stack slot)</li>
+
+<li><tt>isStoreToStackSlot</tt> (if the specified machine instruction is a
+direct store to a stack slot, return the register number of the destination and
+the FrameIndex of the stack slot)</li>
+
+<li><tt>copyRegToReg</tt> (copy values between a pair of registers)</li>
+
+<li><tt>storeRegToStackSlot</tt> (store a register value to a stack slot)</li>
+
+<li><tt>loadRegFromStackSlot</tt> (load a register value from a stack slot)</li>
+
+<li><tt>storeRegToAddr</tt> (store a register value to memory)</li>
+
+<li><tt>loadRegFromAddr</tt> (load a register value from memory)</li>
+
+<li><tt>foldMemoryOperand</tt> (attempt to combine instructions of any load or
+store instruction for the specified operand(s))</li>
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="branchFolding">Branch Folding and If Conversion</a>
+</div>
+<div class="doc_text">
+<p>Performance can be improved by combining instructions or by eliminating
+instructions that are never reached. The <tt>AnalyzeBranch</tt> method in XXXInstrInfo may
+be implemented to examine conditional instructions and remove unnecessary
+instructions. <tt>AnalyzeBranch</tt> looks at the end of a machine basic block (MBB) for
+opportunities for improvement, such as branch folding and if conversion. The
+<tt>BranchFolder</tt> and <tt>IfConverter</tt> machine function passes (see the source files
+<tt>BranchFolding.cpp</tt> and <tt>IfConversion.cpp</tt> in the <tt>lib/CodeGen</tt> directory) call
+<tt>AnalyzeBranch</tt> to improve the control flow graph that represents the
+instructions. </p>
+
+<p>Several implementations of <tt>AnalyzeBranch</tt> (for ARM, Alpha, and
+X86) can be examined as models for your own <tt>AnalyzeBranch</tt> implementation. Since
+SPARC does not implement a useful <tt>AnalyzeBranch</tt>, the ARM target implementation
+is shown below.</p>
+
+<p><tt>AnalyzeBranch</tt> returns a Boolean value and takes four parameters:</p>
+<ul>
+<li>MachineBasicBlock &MBB – the incoming block to be
+examined</li>
+
+<li>MachineBasicBlock *&TBB – a destination block that is
+returned; for a conditional branch that evaluates to true, TBB is the
+destination </li>
+
+<li>MachineBasicBlock *&FBB – for a conditional branch that
+evaluates to false, FBB is returned as the destination</li>
+
+<li>std::vector<MachineOperand> &Cond – list of
+operands to evaluate a condition for a conditional branch</li>
+</ul>
+
+<p>In the simplest case, if a block ends without a branch, then it
+falls through to the successor block. No destination blocks are specified for
+either TBB or FBB, so both parameters return NULL. The start of the <tt>AnalyzeBranch</tt>
+(see code below for the ARM target) shows the function parameters and the code
+for the simplest case.</p>
+</div>
+
+<div class="doc_code">
+<pre>bool ARMInstrInfo::AnalyzeBranch(MachineBasicBlock &MBB,
+ MachineBasicBlock *&TBB, MachineBasicBlock *&FBB,
+ std::vector<MachineOperand> &Cond) const
+{
+ MachineBasicBlock::iterator I = MBB.end();
+ if (I == MBB.begin() || !isUnpredicatedTerminator(--I))
+ return false;
+</pre>
+</div>
+
+<div class="doc_text">
+<p>If a block ends with a single unconditional branch instruction,
+then <tt>AnalyzeBranch</tt> (shown below) should return the destination of that branch
+in the TBB parameter. </p>
+</div>
+
+<div class="doc_code">
+<pre>if (LastOpc == ARM::B || LastOpc == ARM::tB) {
+ TBB = LastInst->getOperand(0).getMBB();
+ return false;
+ }
+</pre>
+</div>
+
+<div class="doc_text">
+<p>If a block ends with two unconditional branches, then the second
+branch is never reached. In that situation, as shown below, remove the last
+branch instruction and return the penultimate branch in the TBB parameter. </p>
+</div>
+
+<div class="doc_code">
+<pre>if ((SecondLastOpc == ARM::B || SecondLastOpc==ARM::tB) &&
+ (LastOpc == ARM::B || LastOpc == ARM::tB)) {
+ TBB = SecondLastInst->getOperand(0).getMBB();
+ I = LastInst;
+ I->eraseFromParent();
+ return false;
+ }
+</pre>
+</div>
+<div class="doc_text">
+<p>A block may end with a single conditional branch instruction that
+falls through to successor block if the condition evaluates to false. In that
+case, <tt>AnalyzeBranch</tt> (shown below) should return the destination of that
+conditional branch in the TBB parameter and a list of operands in the <tt>Cond</tt>
+parameter to evaluate the condition. </p>
+</div>
+
+<div class="doc_code">
+<pre>if (LastOpc == ARM::Bcc || LastOpc == ARM::tBcc) {
+ // Block ends with fall-through condbranch.
+ TBB = LastInst->getOperand(0).getMBB();
+ Cond.push_back(LastInst->getOperand(1));
+ Cond.push_back(LastInst->getOperand(2));
+ return false;
+ }
+</pre>
+</div>
+
+<div class="doc_text">
+<p>If a block ends with both a conditional branch and an ensuing
+unconditional branch, then <tt>AnalyzeBranch</tt> (shown below) should return the
+conditional branch destination (assuming it corresponds to a conditional
+evaluation of ‘true’) in the TBB parameter and the unconditional branch
+destination in the FBB (corresponding to a conditional evaluation of ‘false’).
+A list of operands to evaluate the condition should be returned in the <tt>Cond</tt>
+parameter.</p>
+</div>
+
+<div class="doc_code">
+<pre>unsigned SecondLastOpc = SecondLastInst->getOpcode();
+ if ((SecondLastOpc == ARM::Bcc && LastOpc == ARM::B) ||
+ (SecondLastOpc == ARM::tBcc && LastOpc == ARM::tB)) {
+ TBB = SecondLastInst->getOperand(0).getMBB();
+ Cond.push_back(SecondLastInst->getOperand(1));
+ Cond.push_back(SecondLastInst->getOperand(2));
+ FBB = LastInst->getOperand(0).getMBB();
+ return false;
+ }
+</pre>
+</div>
+
+<div class="doc_text">
+<p>For the last two cases (ending with a single conditional branch or
+ending with one conditional and one unconditional branch), the operands returned
+in the <tt>Cond</tt> parameter can be passed to methods of other instructions to create
+new branches or perform other operations. An implementation of <tt>AnalyzeBranch</tt>
+requires the helper methods <tt>RemoveBranch</tt> and <tt>InsertBranch</tt> to manage subsequent
+operations.</p>
+
+<p><tt>AnalyzeBranch</tt> should return false indicating success in most circumstances.
+<tt>AnalyzeBranch</tt> should only return true when the method is stumped about what to
+do, for example, if a block has three terminating branches. <tt>AnalyzeBranch</tt> may
+return true if it encounters a terminator it cannot handle, such as an indirect
+branch.</p>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="InstructionSelector">Instruction Selector</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+<p>LLVM uses a SelectionDAG to represent LLVM IR instructions, and nodes
+of the SelectionDAG ideally represent native target instructions. During code
+generation, instruction selection passes are performed to convert non-native
+DAG instructions into native target-specific instructions. The pass described
+in <tt>XXXISelDAGToDAG.cpp</tt> is used to match patterns and perform DAG-to-DAG
+instruction selection. Optionally, a pass may be defined (in
+<tt>XXXBranchSelector.cpp</tt>) to perform similar DAG-to-DAG operations for branch
+instructions. Later,
+the code in <tt>XXXISelLowering.cpp</tt> replaces or removes operations and data types
+not supported natively (legalizes) in a Selection DAG. </p>
+
+<p>TableGen generates code for instruction selection using the
+following target description input files:</p>
+<ul>
+<li><tt>XXXInstrInfo.td</tt> contains definitions of instructions in a
+target-specific instruction set, generates <tt>XXXGenDAGISel.inc</tt>, which is included
+in <tt>XXXISelDAGToDAG.cpp</tt>. </li>
+
+<li><tt>XXXCallingConv.td</tt> contains the calling and return value conventions
+for the target architecture, and it generates <tt>XXXGenCallingConv.inc</tt>, which is
+included in <tt>XXXISelLowering.cpp</tt>.</li>
+</ul>
+
+<p>The implementation of an instruction selection pass must include
+a header that declares the FunctionPass class or a subclass of FunctionPass. In
+<tt>XXXTargetMachine.cpp</tt>, a Pass Manager (PM) should add each instruction selection
+pass into the queue of passes to run.</p>
+
+<p>The LLVM static
+compiler (<tt>llc</tt>) is an excellent tool for visualizing the contents of DAGs. To display
+the SelectionDAG before or after specific processing phases, use the command
+line options for <tt>llc</tt>, described at <a
+href="http://llvm.org/docs/CodeGenerator.html#selectiondag_process">
+SelectionDAG Instruction Selection Process</a>.
+</p>
+
+<p>To describe instruction selector behavior, you should add
+patterns for lowering LLVM code into a SelectionDAG as the last parameter of
+the instruction definitions in <tt>XXXInstrInfo.td</tt>. For example, in
+<tt>SparcInstrInfo.td</tt>, this entry defines a register store operation, and the last
+parameter describes a pattern with the store DAG operator.</p>
+</div>
+
+<div class="doc_code">
+<pre>def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
+ "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;
+</pre>
+</div>
+
+<div class="doc_text">
+<p>ADDRrr is a memory mode that is also defined in <tt>SparcInstrInfo.td</tt>:</p>
+</div>
+
+<div class="doc_code">
+<pre>def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
+</pre>
+</div>
+
+<div class="doc_text">
+<p>The definition of ADDRrr refers to SelectADDRrr, which is a function defined in an
+implementation of the Instructor Selector (such as <tt>SparcISelDAGToDAG.cpp</tt>). </p>
+
+<p>In <tt>lib/Target/TargetSelectionDAG.td</tt>, the DAG operator for store
+is defined below:</p>
+</div>
+
+<div class="doc_code">
+<pre>def store : PatFrag<(ops node:$val, node:$ptr),
+ (st node:$val, node:$ptr), [{
+ if (StoreSDNode *ST = dyn_cast<StoreSDNode>(N))
+ return !ST->isTruncatingStore() &&
+ ST->getAddressingMode() == ISD::UNINDEXED;
+ return false;
+}]>;
+</pre>
+</div>
+<div class="doc_text">
+<p><tt>XXXInstrInfo.td</tt> also generates (in <tt>XXXGenDAGISel.inc</tt>) the
+<tt>SelectCode</tt> method that is used to call the appropriate processing method for an
+instruction. In this example, <tt>SelectCode</tt> calls <tt>Select_ISD_STORE</tt> for the
+ISD::STORE opcode.</p>
+</div>
+
+<div class="doc_code">
+<pre>SDNode *SelectCode(SDOperand N) {
+ ...
+ MVT::ValueType NVT = N.Val->getValueType(0);
+ switch (N.getOpcode()) {
+ case ISD::STORE: {
+ switch (NVT) {
+ default:
+ return Select_ISD_STORE(N);
+ break;
+ }
+ break;
+ }
+ ...
+</pre>
+</div>
+<div class="doc_text">
+<p>The pattern for STrr is matched, so elsewhere in
+<tt>XXXGenDAGISel.inc</tt>, code for STrr is created for <tt>Select_ISD_STORE</tt>. The <tt>Emit_22</tt> method
+is also generated in <tt>XXXGenDAGISel.inc</tt> to complete the processing of this
+instruction. </p>
+</div>
+
+<div class="doc_code">
+<pre>SDNode *Select_ISD_STORE(const SDOperand &N) {
+ SDOperand Chain = N.getOperand(0);
+ if (Predicate_store(N.Val)) {
+ SDOperand N1 = N.getOperand(1);
+ SDOperand N2 = N.getOperand(2);
+ SDOperand CPTmp0;
+ SDOperand CPTmp1;
+
+ // Pattern: (st:void IntRegs:i32:$src,
+ // ADDRrr:i32:$addr)<<P:Predicate_store>>
+ // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src)
+ // Pattern complexity = 13 cost = 1 size = 0
+ if (SelectADDRrr(N, N2, CPTmp0, CPTmp1) &&
+ N1.Val->getValueType(0) == MVT::i32 &&
+ N2.Val->getValueType(0) == MVT::i32) {
+ return Emit_22(N, SP::STrr, CPTmp0, CPTmp1);
+ }
+...
+</pre>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="LegalizePhase">The SelectionDAG Legalize Phase</a>
+</div>
+<div class="doc_text">
+<p>The Legalize phase converts a DAG to use types and operations
+that are natively supported by the target. For natively unsupported types and
+operations, you need to add code to the target-specific XXXTargetLowering implementation
+to convert unsupported types and operations to supported ones.</p>
+
+<p>In the constructor for the XXXTargetLowering class, first use the
+<tt>addRegisterClass</tt> method to specify which types are supports and which register
+classes are associated with them. The code for the register classes are generated
+by TableGen from <tt>XXXRegisterInfo.td</tt> and placed in <tt>XXXGenRegisterInfo.h.inc</tt>. For
+example, the implementation of the constructor for the SparcTargetLowering
+class (in <tt>SparcISelLowering.cpp</tt>) starts with the following code:</p>
+</div>
+
+<div class="doc_code">
+<pre>addRegisterClass(MVT::i32, SP::IntRegsRegisterClass);
+addRegisterClass(MVT::f32, SP::FPRegsRegisterClass);
+addRegisterClass(MVT::f64, SP::DFPRegsRegisterClass);
+</pre>
+</div>
+
+<div class="doc_text">
+<p>You should examine the node types in the ISD namespace
+(<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>)
+and determine which operations the target natively supports. For operations
+that do <u>not</u> have native support, add a callback to the constructor for
+the XXXTargetLowering class, so the instruction selection process knows what to
+do. The TargetLowering class callback methods (declared in
+<tt>llvm/Target/TargetLowering.h</tt>) are:</p>
+<ul>
+<li><tt>setOperationAction</tt> (general operation)</li>
+
+<li><tt>setLoadExtAction</tt> (load with extension)</li>
+
+<li><tt>setTruncStoreAction</tt> (truncating store)</li>
+
+<li><tt>setIndexedLoadAction</tt> (indexed load)</li>
+
+<li><tt>setIndexedStoreAction</tt> (indexed store)</li>
+
+<li><tt>setConvertAction</tt> (type conversion)</li>
+
+<li><tt>setCondCodeAction</tt> (support for a given condition code)</li>
+</ul>
+
+<p>Note: on older releases, <tt>setLoadXAction</tt> is used instead of <tt>setLoadExtAction</tt>.
+Also, on older releases, <tt>setCondCodeAction</tt> may not be supported. Examine your
+release to see what methods are specifically supported.</p>
+
+<p>These callbacks are used to determine that an operation does or
+does not work with a specified type (or types). And in all cases, the third
+parameter is a LegalAction type enum value: <tt>Promote</tt>, <tt>Expand</tt>,
+<tt>Custom</tt>, or <tt>Legal</tt>. <tt>SparcISelLowering.cpp</tt>
+contains examples of all four LegalAction values.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="promote">Promote</a>
+</div>
+
+<div class="doc_text">
+<p>For an operation without native support for a given type, the
+specified type may be promoted to a larger type that is supported. For example,
+SPARC does not support a sign-extending load for Boolean values (<tt>i1</tt> type), so
+in <tt>SparcISelLowering.cpp</tt> the third
+parameter below, <tt>Promote</tt>, changes <tt>i1</tt> type
+values to a large type before loading.</p>
+</div>
+
+<div class="doc_code">
+<pre>setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="expand">Expand</a>
+</div>
+<div class="doc_text">
+<p>For a type without native support, a value may need to be broken
+down further, rather than promoted. For an operation without native support, a
+combination of other operations may be used to similar effect. In SPARC, the
+floating-point sine and cosine trig operations are supported by expansion to
+other operations, as indicated by the third parameter, <tt>Expand</tt>, to
+<tt>setOperationAction</tt>:</p>
+</div>
+
+<div class="doc_code">
+<pre>setOperationAction(ISD::FSIN, MVT::f32, Expand);
+setOperationAction(ISD::FCOS, MVT::f32, Expand);
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="custom">Custom</a>
+</div>
+<div class="doc_text">
+<p>For some operations, simple type promotion or operation expansion
+may be insufficient. In some cases, a special intrinsic function must be
+implemented. </p>
+
+<p>For example, a constant value may require special treatment, or
+an operation may require spilling and restoring registers in the stack and
+working with register allocators. </p>
+
+<p>As seen in <tt>SparcISelLowering.cpp</tt> code below, to perform a type
+conversion from a floating point value to a signed integer, first the
+<tt>setOperationAction</tt> should be called with <tt>Custom</tt> as the third parameter:</p>
+</div>
+
+<div class="doc_code">
+<pre>setOperationAction(ISD::FP_TO_SINT, MVT::i32, Custom);
+</pre>
+</div>
+<div class="doc_text">
+<p>In the <tt>LowerOperation</tt> method, for each <tt>Custom</tt> operation, a case
+statement should be added to indicate what function to call. In the following
+code, an FP_TO_SINT opcode will call the <tt>LowerFP_TO_SINT</tt> method:</p>
+</div>
+
+<div class="doc_code">
+<pre>SDOperand SparcTargetLowering::LowerOperation(
+ SDOperand Op, SelectionDAG &DAG) {
+ switch (Op.getOpcode()) {
+ case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG);
+ ...
+ }
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>Finally, the <tt>LowerFP_TO_SINT</tt> method is implemented, using an FP
+register to convert the floating-point value to an integer.</p>
+</div>
+
+<div class="doc_code">
+<pre>static SDOperand LowerFP_TO_SINT(SDOperand Op, SelectionDAG &DAG) {
+assert(Op.getValueType() == MVT::i32);
+ Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0));
+ return DAG.getNode(ISD::BIT_CONVERT, MVT::i32, Op);
+}
+</pre>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="legal">Legal</a>
+</div>
+<div class="doc_text">
+<p>The <tt>Legal</tt> LegalizeAction enum value simply indicates that an
+operation <u>is</u> natively supported. <tt>Legal</tt> represents the default condition,
+so it is rarely used. In <tt>SparcISelLowering.cpp</tt>, the action for CTPOP (an
+operation to count the bits set in an integer) is natively supported only for
+SPARC v9. The following code enables the <tt>Expand</tt> conversion technique for non-v9
+SPARC implementations.</p>
+</div>
+
+<div class="doc_code">
+<pre>setOperationAction(ISD::CTPOP, MVT::i32, Expand);
+...
+if (TM.getSubtarget<SparcSubtarget>().isV9())
+ setOperationAction(ISD::CTPOP, MVT::i32, Legal);
+ case ISD::SETULT: return SPCC::ICC_CS;
+ case ISD::SETULE: return SPCC::ICC_LEU;
+ case ISD::SETUGT: return SPCC::ICC_GU;
+ case ISD::SETUGE: return SPCC::ICC_CC;
+ }
+}
+</pre>
+</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="callingConventions">Calling Conventions</a>
+</div>
+<div class="doc_text">
+<p>To support target-specific calling conventions, <tt>XXXGenCallingConv.td</tt>
+uses interfaces (such as CCIfType and CCAssignToReg) that are defined in
+<tt>lib/Target/TargetCallingConv.td</tt>. TableGen can take the target descriptor file
+<tt>XXXGenCallingConv.td</tt> and generate the header file <tt>XXXGenCallingConv.inc</tt>, which
+is typically included in <tt>XXXISelLowering.cpp</tt>. You can use the interfaces in
+<tt>TargetCallingConv.td</tt> to specify:</p>
+<ul>
+<li>the order of parameter allocation</li>
+
+<li>where parameters and return values are placed (that is, on the
+stack or in registers)</li>
+
+<li>which registers may be used</li>
+
+<li>whether the caller or callee unwinds the stack</li>
+</ul>
+
+<p>The following example demonstrates the use of the CCIfType and
+CCAssignToReg interfaces. If the CCIfType predicate is true (that is, if the
+current argument is of type f32 or f64), then the action is performed. In this
+case, the CCAssignToReg action assigns the argument value to the first
+available register: either R0 or R1. </p>
+</div>
+<div class="doc_code">
+<pre>CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
+</pre>
+</div>
+<div class="doc_text">
+<p><tt>SparcCallingConv.td</tt> contains definitions for a target-specific return-value
+calling convention (RetCC_Sparc32) and a basic 32-bit C calling convention
+(CC_Sparc32). The definition of RetCC_Sparc32 (shown below) indicates which
+registers are used for specified scalar return types. A single-precision float
+is returned to register F0, and a double-precision float goes to register D0. A
+32-bit integer is returned in register I0 or I1. </p>
+</div>
+
+<div class="doc_code">
+<pre>def RetCC_Sparc32 : CallingConv<[
+ CCIfType<[i32], CCAssignToReg<[I0, I1]>>,
+ CCIfType<[f32], CCAssignToReg<[F0]>>,
+ CCIfType<[f64], CCAssignToReg<[D0]>>
+]>;
+</pre>
+</div>
+<div class="doc_text">
+<p>The definition of CC_Sparc32 in <tt>SparcCallingConv.td</tt> introduces
+CCAssignToStack, which assigns the value to a stack slot with the specified size
+and alignment. In the example below, the first parameter, 4, indicates the size
+of the slot, and the second parameter, also 4, indicates the stack alignment
+along 4-byte units. (Special cases: if size is zero, then the ABI size is used;
+if alignment is zero, then the ABI alignment is used.) </p>
+</div>
+
+<div class="doc_code">
+<pre>def CC_Sparc32 : CallingConv<[
+ // All arguments get passed in integer registers if there is space.
+ CCIfType<[i32, f32, f64], CCAssignToReg<[I0, I1, I2, I3, I4, I5]>>,
+ CCAssignToStack<4, 4>
+]>;
+</pre>
+</div>
+<div class="doc_text">
+<p>CCDelegateTo is another commonly used interface, which tries to find
+a specified sub-calling convention and, if a match is found, it is invoked. In
+the following example (in <tt>X86CallingConv.td</tt>), the definition of RetCC_X86_32_C
+ends with CCDelegateTo. After the current value is assigned to the register ST0
+or ST1, the RetCC_X86Common is invoked.</p>
+</div>
+
+<div class="doc_code">
+<pre>def RetCC_X86_32_C : CallingConv<[
+ CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>,
+ CCIfType<[f64], CCAssignToReg<[ST0, ST1]>>,
+ CCDelegateTo<RetCC_X86Common>
+]>;
+</pre>
+</div>
+<div class="doc_text">
+<p>CCIfCC is an interface that attempts to match the given name to
+the current calling convention. If the name identifies the current calling
+convention, then a specified action is invoked. In the following example (in
+<tt>X86CallingConv.td</tt>), if the Fast calling convention is in use, then RetCC_X86_32_Fast
+is invoked. If the SSECall calling convention is in use, then RetCC_X86_32_SSE
+is invoked. </p>
+</div>
+
+<div class="doc_code">
+<pre>def RetCC_X86_32 : CallingConv<[
+ CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
+ CCIfCC<"CallingConv::X86_SSECall", CCDelegateTo<RetCC_X86_32_SSE>>,
+ CCDelegateTo<RetCC_X86_32_C>
+]>;
+</pre>
+</div>
+<div class="doc_text">
+<p>Other calling convention interfaces include:</p>
+<ul>
+<li>CCIf <predicate, action> - if the predicate matches, apply
+the action</li>
+
+<li>CCIfInReg <action> - if the argument is marked with the
+‘inreg’ attribute, then apply the action </li>
+
+<li>CCIfNest <action> - if the argument is marked with the
+‘nest’ attribute, then apply the action</li>
+
+<li>CCIfNotVarArg <action> - if the current function does not
+take a variable number of arguments, apply the action</li>
+
+<li>CCAssignToRegWithShadow <registerList, shadowList> -
+similar to CCAssignToReg, but with a shadow list of registers</li>
+
+<li>CCPassByVal <size, align> - assign value to a stack slot
+with the minimum specified size and alignment </li>
+
+<li>CCPromoteToType <type> - promote the current value to the specified
+type</li>
+
+<li>CallingConv <[actions]> - define each calling convention
+that is supported</li>
+</ul>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="assemblyPrinter">Assembly Printer</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+<p>During the code
+emission stage, the code generator may utilize an LLVM pass to produce assembly
+output. To do this, you want to implement the code for a printer that converts
+LLVM IR to a GAS-format assembly language for your target machine, using the
+following steps:</p>
+<ul>
+<li>Define all the assembly strings for your target, adding them to
+the instructions defined in the <tt>XXXInstrInfo.td</tt> file.
+(See <a href="#InstructionSet">Instruction Set</a>.)
+TableGen will produce an output file (<tt>XXXGenAsmWriter.inc</tt>) with an
+implementation of the <tt>printInstruction</tt> method for the XXXAsmPrinter class.</li>
+
+<li>Write <tt>XXXTargetAsmInfo.h</tt>, which contains the bare-bones
+declaration of the XXXTargetAsmInfo class (a subclass of TargetAsmInfo). </li>
+
+<li>Write <tt>XXXTargetAsmInfo.cpp</tt>, which contains target-specific values
+for TargetAsmInfo properties and sometimes new implementations for methods</li>
+
+<li>Write <tt>XXXAsmPrinter.cpp</tt>, which implements the AsmPrinter class
+that performs the LLVM-to-assembly conversion. </li>
+</ul>
+
+<p>The code in <tt>XXXTargetAsmInfo.h</tt> is usually a trivial declaration
+of the XXXTargetAsmInfo class for use in <tt>XXXTargetAsmInfo.cpp</tt>. Similarly,
+<tt>XXXTargetAsmInfo.cpp</tt> usually has a few declarations of XXXTargetAsmInfo replacement
+values that override the default values in <tt>TargetAsmInfo.cpp</tt>. For example in
+<tt>SparcTargetAsmInfo.cpp</tt>, </p>
+</div>
+
+<div class="doc_code">
+<pre>SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) {
+ Data16bitsDirective = "\t.half\t";
+ Data32bitsDirective = "\t.word\t";
+ Data64bitsDirective = 0; // .xword is only supported by V9.
+ ZeroDirective = "\t.skip\t";
+ CommentString = "!";
+ ConstantPoolSection = "\t.section \".rodata\",#alloc\n";
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>The X86 assembly printer implementation (X86TargetAsmInfo) is an
+example where the target specific TargetAsmInfo class uses overridden methods:
+<tt>ExpandInlineAsm</tt> and <tt>PreferredEHDataFormat</tt>. </p>
+
+<p>A target-specific implementation of AsmPrinter is written in
+<tt>XXXAsmPrinter.cpp</tt>, which implements the AsmPrinter class that converts the LLVM
+to printable assembly. The implementation must include the following headers
+that have declarations for the AsmPrinter and MachineFunctionPass classes. The
+MachineFunctionPass is a subclass of FunctionPass. </p>
+</div>
+
+<div class="doc_code">
+<pre>#include "llvm/CodeGen/AsmPrinter.h"
+#include "llvm/CodeGen/MachineFunctionPass.h"
+</pre>
+</div>
+
+<div class="doc_text">
+<p>As a FunctionPass, AsmPrinter first calls <tt>doInitialization</tt> to set
+up the AsmPrinter. In SparcAsmPrinter, a Mangler object is instantiated to
+process variable names.</p>
+
+<p>In <tt>XXXAsmPrinter.cpp</tt>, the <tt>runOnMachineFunction</tt> method (declared
+in MachineFunctionPass) must be implemented for XXXAsmPrinter. In
+MachineFunctionPass, the <tt>runOnFunction</tt> method invokes <tt>runOnMachineFunction</tt>.
+Target-specific implementations of <tt>runOnMachineFunction</tt> differ, but generally
+do the following to process each machine function:</p>
+<ul>
+<li>call <tt>SetupMachineFunction</tt> to perform initialization</li>
+
+<li>call <tt>EmitConstantPool</tt> to print out (to the output stream)
+constants which have been spilled to memory </li>
+
+<li>call <tt>EmitJumpTableInfo</tt> to print out jump tables used by the
+current function </li>
+
+<li>print out the label for the current function</li>
+
+<li>print out the code for the function, including basic block labels
+and the assembly for the instruction (using <tt>printInstruction</tt>)</li>
+</ul>
+<p>The XXXAsmPrinter implementation must also include the code
+generated by TableGen that is output in the <tt>XXXGenAsmWriter.inc</tt> file. The code
+in <tt>XXXGenAsmWriter.inc</tt> contains an implementation of the <tt>printInstruction</tt>
+method that may call these methods:</p>
+<ul>
+<li><tt>printOperand</tt></li>
+
+<li><tt>printMemOperand</tt></li>
+
+<li><tt>printCCOperand (for conditional statements)</tt></li>
+
+<li><tt>printDataDirective</tt></li>
+
+<li><tt>printDeclare</tt></li>
+
+<li><tt>printImplicitDef</tt></li>
+
+<li><tt>printInlineAsm</tt></li>
+
+<li><tt>printLabel</tt></li>
+
+<li><tt>printPICJumpTableEntry</tt></li>
+
+<li><tt>printPICJumpTableSetLabel</tt></li>
+</ul>
+
+<p>The implementations of <tt>printDeclare</tt>, <tt>printImplicitDef</tt>,
+<tt>printInlineAsm</tt>, and <tt>printLabel</tt> in <tt>AsmPrinter.cpp</tt> are generally adequate for
+printing assembly and do not need to be overridden. (<tt>printBasicBlockLabel</tt> is
+another method that is implemented in <tt>AsmPrinter.cpp</tt> that may be directly used
+in an implementation of XXXAsmPrinter.)</p>
+
+<p>The <tt>printOperand</tt> method is implemented with a long switch/case
+statement for the type of operand: register, immediate, basic block, external
+symbol, global address, constant pool index, or jump table index. For an
+instruction with a memory address operand, the <tt>printMemOperand</tt> method should be
+implemented to generate the proper output. Similarly, <tt>printCCOperand</tt> should be
+used to print a conditional operand. </p>
+
+<p><tt>doFinalization</tt> should be overridden in XXXAsmPrinter, and
+it should be called to shut down the assembly printer. During <tt>doFinalization</tt>,
+global variables and constants are printed to output.</p>
+</div>
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="subtargetSupport">Subtarget Support</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+<p>Subtarget support is used to inform the code generation process
+of instruction set variations for a given chip set. For example, the LLVM
+SPARC implementation provided covers three major versions of the SPARC
+microprocessor architecture: Version 8 (V8, which is a 32-bit architecture),
+Version 9 (V9, a 64-bit architecture), and the UltraSPARC architecture. V8 has
+16 double-precision floating-point registers that are also usable as either 32
+single-precision or 8 quad-precision registers. V8 is also purely big-endian. V9
+has 32 double-precision floating-point registers that are also usable as 16
+quad-precision registers, but cannot be used as single-precision registers. The
+UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set
+extensions.</p>
+
+<p>If subtarget support is needed, you should implement a
+target-specific XXXSubtarget class for your architecture. This class should
+process the command-line options <tt>–mcpu=</tt> and <tt>–mattr=</tt></p>
+
+<p>TableGen uses definitions in the <tt>Target.td</tt> and <tt>Sparc.td</tt> files to
+generate code in <tt>SparcGenSubtarget.inc</tt>. In <tt>Target.td</tt>, shown below, the
+SubtargetFeature interface is defined. The first 4 string parameters of the
+SubtargetFeature interface are a feature name, an attribute set by the feature,
+the value of the attribute, and a description of the feature. (The fifth
+parameter is a list of features whose presence is implied, and its default
+value is an empty array.)</p>
+</div>
+
+<div class="doc_code">
+<pre>class SubtargetFeature<string n, string a, string v, string d,
+ list<SubtargetFeature> i = []> {
+ string Name = n;
+ string Attribute = a;
+ string Value = v;
+ string Desc = d;
+ list<SubtargetFeature> Implies = i;
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>In the <tt>Sparc.td</tt> file, the SubtargetFeature is used to define the
+following features. </p>
+</div>
+
+<div class="doc_code">
+<pre>def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true",
+ "Enable SPARC-V9 instructions">;
+def FeatureV8Deprecated : SubtargetFeature<"deprecated-v8",
+ "V8DeprecatedInsts", "true",
+ "Enable deprecated V8 instructions in V9 mode">;
+def FeatureVIS : SubtargetFeature<"vis", "IsVIS", "true",
+ "Enable UltraSPARC Visual Instruction Set extensions">;
+</pre>
+</div>
+
+<div class="doc_text">
+<p>Elsewhere in <tt>Sparc.td</tt>, the Proc class is defined and then is used
+to define particular SPARC processor subtypes that may have the previously
+described features. </p>
+</div>
+
+<div class="doc_code">
+<pre>class Proc<string Name, list<SubtargetFeature> Features>
+ : Processor<Name, NoItineraries, Features>;
+
+def : Proc<"generic", []>;
+def : Proc<"v8", []>;
+def : Proc<"supersparc", []>;
+def : Proc<"sparclite", []>;
+def : Proc<"f934", []>;
+def : Proc<"hypersparc", []>;
+def : Proc<"sparclite86x", []>;
+def : Proc<"sparclet", []>;
+def : Proc<"tsc701", []>;
+def : Proc<"v9", [FeatureV9]>;
+def : Proc<"ultrasparc", [FeatureV9, FeatureV8Deprecated]>;
+def : Proc<"ultrasparc3", [FeatureV9, FeatureV8Deprecated]>;
+def : Proc<"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]>;
+</pre>
+</div>
+
+<div class="doc_text">
+<p>From <tt>Target.td</tt> and <tt>Sparc.td</tt> files, the resulting
+SparcGenSubtarget.inc specifies enum values to identify the features, arrays of
+constants to represent the CPU features and CPU subtypes, and the
+ParseSubtargetFeatures method that parses the features string that sets
+specified subtarget options. The generated <tt>SparcGenSubtarget.inc</tt> file should be
+included in the <tt>SparcSubtarget.cpp</tt>. The target-specific implementation of the XXXSubtarget
+method should follow this pseudocode:</p>
+</div>
+
+<div class="doc_code">
+<pre>XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) {
+ // Set the default features
+ // Determine default and user specified characteristics of the CPU
+ // Call ParseSubtargetFeatures(FS, CPU) to parse the features string
+ // Perform any additional operations
+}
+</pre>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="jitSupport">JIT Support</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+<p>The implementation of a target machine optionally includes a Just-In-Time
+(JIT) code generator that emits machine code and auxiliary structures as binary
+output that can be written directly to memory.
+To do this, implement JIT code generation by performing the following
+steps:</p>
+<ul>
+<li>Write an <tt>XXXCodeEmitter.cpp</tt> file that contains a machine function
+pass that transforms target-machine instructions into relocatable machine code.</li>
+
+<li>Write an <tt>XXXJITInfo.cpp</tt> file that implements the JIT interfaces
+for target-specific code-generation
+activities, such as emitting machine code and stubs. </li>
+
+<li>Modify XXXTargetMachine so that it provides a TargetJITInfo
+object through its <tt>getJITInfo</tt> method. </li>
+</ul>
+
+<p>There are several different approaches to writing the JIT support
+code. For instance, TableGen and target descriptor files may be used for
+creating a JIT code generator, but are not mandatory. For the Alpha and PowerPC
+target machines, TableGen is used to generate <tt>XXXGenCodeEmitter.inc</tt>, which
+contains the binary coding of machine instructions and the
+<tt>getBinaryCodeForInstr</tt> method to access those codes. Other JIT implementations
+do not.</p>
+
+<p>Both <tt>XXXJITInfo.cpp</tt> and <tt>XXXCodeEmitter.cpp</tt> must include the
+<tt>llvm/CodeGen/MachineCodeEmitter.h</tt> header file that defines the MachineCodeEmitter
+class containing code for several callback functions that write data (in bytes,
+words, strings, etc.) to the output stream.</p>
+</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="mce">Machine Code Emitter</a>
+</div>
+
+<div class="doc_text">
+<p>In <tt>XXXCodeEmitter.cpp</tt>, a target-specific of the Emitter class is
+implemented as a function pass (subclass of MachineFunctionPass). The
+target-specific implementation of <tt>runOnMachineFunction</tt> (invoked by
+<tt>runOnFunction</tt> in MachineFunctionPass) iterates through the MachineBasicBlock
+calls <tt>emitInstruction</tt> to process each instruction and emit binary code. <tt>emitInstruction</tt>
+is largely implemented with case statements on the instruction types defined in
+<tt>XXXInstrInfo.h</tt>. For example, in <tt>X86CodeEmitter.cpp</tt>, the <tt>emitInstruction</tt> method
+is built around the following switch/case statements:</p>
+</div>
+
+<div class="doc_code">
+<pre>switch (Desc->TSFlags & X86::FormMask) {
+case X86II::Pseudo: // for not yet implemented instructions
+ ... // or pseudo-instructions
+ break;
+case X86II::RawFrm: // for instructions with a fixed opcode value
+ ...
+ break;
+case X86II::AddRegFrm: // for instructions that have one register operand
+ ... // added to their opcode
+ break;
+case X86II::MRMDestReg:// for instructions that use the Mod/RM byte
+ ... // to specify a destination (register)
+ break;
+case X86II::MRMDestMem:// for instructions that use the Mod/RM byte
+ ... // to specify a destination (memory)
+ break;
+case X86II::MRMSrcReg: // for instructions that use the Mod/RM byte
+ ... // to specify a source (register)
+ break;
+case X86II::MRMSrcMem: // for instructions that use the Mod/RM byte
+ ... // to specify a source (memory)
+ break;
+case X86II::MRM0r: case X86II::MRM1r: // for instructions that operate on
+case X86II::MRM2r: case X86II::MRM3r: // a REGISTER r/m operand and
+case X86II::MRM4r: case X86II::MRM5r: // use the Mod/RM byte and a field
+case X86II::MRM6r: case X86II::MRM7r: // to hold extended opcode data
+ ...
+ break;
+case X86II::MRM0m: case X86II::MRM1m: // for instructions that operate on
+case X86II::MRM2m: case X86II::MRM3m: // a MEMORY r/m operand and
+case X86II::MRM4m: case X86II::MRM5m: // use the Mod/RM byte and a field
+case X86II::MRM6m: case X86II::MRM7m: // to hold extended opcode data
+ ...
+ break;
+case X86II::MRMInitReg: // for instructions whose source and
+ ... // destination are the same register
+ break;
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>The implementations of these case statements often first emit the
+opcode and then get the operand(s). Then depending upon the operand, helper
+methods may be called to process the operand(s). For example, in <tt>X86CodeEmitter.cpp</tt>,
+for the <tt>X86II::AddRegFrm</tt> case, the first data emitted (by <tt>emitByte</tt>) is the
+opcode added to the register operand. Then an object representing the machine
+operand, MO1, is extracted. The helper methods such as <tt>isImmediate</tt>,
+<tt>isGlobalAddress</tt>, <tt>isExternalSymbol</tt>, <tt>isConstantPoolIndex</tt>, and
+<tt>isJumpTableIndex</tt>
+determine the operand type. (<tt>X86CodeEmitter.cpp</tt> also has private methods such
+as <tt>emitConstant</tt>, <tt>emitGlobalAddress</tt>,
+<tt>emitExternalSymbolAddress</tt>, <tt>emitConstPoolAddress</tt>,
+and <tt>emitJumpTableAddress</tt> that emit the data into the output stream.) </p>
+</div>
+
+<div class="doc_code">
+<pre>case X86II::AddRegFrm:
+ MCE.emitByte(BaseOpcode + getX86RegNum(MI.getOperand(CurOp++).getReg()));
+
+ if (CurOp != NumOps) {
+ const MachineOperand &MO1 = MI.getOperand(CurOp++);
+ unsigned Size = X86InstrInfo::sizeOfImm(Desc);
+ if (MO1.isImmediate())
+ emitConstant(MO1.getImm(), Size);
+ else {
+ unsigned rt = Is64BitMode ? X86::reloc_pcrel_word
+ : (IsPIC ? X86::reloc_picrel_word : X86::reloc_absolute_word);
+ if (Opcode == X86::MOV64ri)
+ rt = X86::reloc_absolute_dword; // FIXME: add X86II flag?
+ if (MO1.isGlobalAddress()) {
+ bool NeedStub = isa<Function>(MO1.getGlobal());
+ bool isLazy = gvNeedsLazyPtr(MO1.getGlobal());
+ emitGlobalAddress(MO1.getGlobal(), rt, MO1.getOffset(), 0,
+ NeedStub, isLazy);
+ } else if (MO1.isExternalSymbol())
+ emitExternalSymbolAddress(MO1.getSymbolName(), rt);
+ else if (MO1.isConstantPoolIndex())
+ emitConstPoolAddress(MO1.getIndex(), rt);
+ else if (MO1.isJumpTableIndex())
+ emitJumpTableAddress(MO1.getIndex(), rt);
+ }
+ }
+ break;
+</pre>
+</div>
+<div class="doc_text">
+<p>In the previous example, <tt>XXXCodeEmitter.cpp</tt> uses the variable <tt>rt</tt>,
+which is a RelocationType enum that may be used to relocate addresses (for
+example, a global address with a PIC base offset). The RelocationType enum for
+that target is defined in the short target-specific <tt>XXXRelocations.h</tt> file. The
+RelocationType is used by the <tt>relocate</tt> method defined in <tt>XXXJITInfo.cpp</tt> to
+rewrite addresses for referenced global symbols.</p>
+
+<p>For example, <tt>X86Relocations.h</tt> specifies the following relocation
+types for the X86 addresses. In all four cases, the relocated value is added to
+the value already in memory. For <tt>reloc_pcrel_word</tt> and <tt>reloc_picrel_word</tt>,
+there is an additional initial adjustment.</p>
+</div>
+
+<div class="doc_code">
+<pre>enum RelocationType {
+ reloc_pcrel_word = 0, // add reloc value after adjusting for the PC loc
+ reloc_picrel_word = 1, // add reloc value after adjusting for the PIC base
+ reloc_absolute_word = 2, // absolute relocation; no additional adjustment
+ reloc_absolute_dword = 3 // absolute relocation; no additional adjustment
+};
+</pre>
+</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="targetJITInfo">Target JIT Info</a>
+</div>
+<div class="doc_text">
+<p><tt>XXXJITInfo.cpp</tt> implements the JIT interfaces for target-specific code-generation
+activities, such as emitting machine code and stubs. At minimum,
+a target-specific version of XXXJITInfo implements the following:</p>
+<ul>
+<li><tt>getLazyResolverFunction</tt> – initializes the JIT, gives the
+target a function that is used for compilation </li>
+
+<li><tt>emitFunctionStub</tt> – returns a native function with a
+specified address for a callback function</li>
+
+<li><tt>relocate</tt> – changes the addresses of referenced globals,
+based on relocation types</li>
+
+<li>callback function that are wrappers to a function stub that is
+used when the real target is not initially known </li>
+</ul>
+
+<p><tt>getLazyResolverFunction</tt> is generally trivial to implement. It
+makes the incoming parameter as the global JITCompilerFunction and returns the
+callback function that will be used a function wrapper. For the Alpha target
+(in <tt>AlphaJITInfo.cpp</tt>), the <tt>getLazyResolverFunction</tt> implementation is simply:</p>
+</div>
+
+<div class="doc_code">
+<pre>TargetJITInfo::LazyResolverFn AlphaJITInfo::getLazyResolverFunction(
+ JITCompilerFn F)
+{
+ JITCompilerFunction = F;
+ return AlphaCompilationCallback;
+}
+</pre>
+</div>
+<div class="doc_text">
+<p>For the X86 target, the <tt>getLazyResolverFunction</tt> implementation is
+a little more complication, because it returns a different callback function
+for processors with SSE instructions and XMM registers. </p>
+
+<p>The callback function initially saves and later restores the
+callee register values, incoming arguments, and frame and return address. The
+callback function needs low-level access to the registers or stack, so it is typically
+implemented with assembler. </p>