+<div class="doc_code">
+<pre>
+def : InstAlias<"movsx $src, $dst", (MOVSX16rr8W GR16:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX16rm8W GR16:$dst, i8mem:$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr8 GR32:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr16 GR32:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr8 GR64:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr16 GR64:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr32 GR64:$dst, GR32 :$src)>;
+</pre>
+</div>
+
+<p>This shows a powerful example of the instruction aliases, matching the
+same mnemonic in multiple different ways depending on what operands are present
+in the assembly. The result of instruction aliases can include operands in a
+different order than the destination instruction, and can use an input
+multiple times, for example:</p>
+
+<div class="doc_code">
+<pre>
+def : InstAlias<"clrb $reg", (XOR8rr GR8 :$reg, GR8 :$reg)>;
+def : InstAlias<"clrw $reg", (XOR16rr GR16:$reg, GR16:$reg)>;
+def : InstAlias<"clrl $reg", (XOR32rr GR32:$reg, GR32:$reg)>;
+def : InstAlias<"clrq $reg", (XOR64rr GR64:$reg, GR64:$reg)>;
+</pre>
+</div>
+
+<p>This example also shows that tied operands are only listed once. In the X86
+backend, XOR8rr has two input GR8's and one output GR8 (where an input is tied
+to the output). InstAliases take a flattened operand list without duplicates
+for tied operands. The result of an instruction alias can also use immediates
+and fixed physical registers which are added as simple immediate operands in the
+result, for example:</p>
+
+<div class="doc_code">
+<pre>
+// Fixed Immediate operand.
+def : InstAlias<"aad", (AAD8i8 10)>;
+
+// Fixed register operand.
+def : InstAlias<"fcomi", (COM_FIr ST1)>;
+
+// Simple alias.
+def : InstAlias<"fcomi $reg", (COM_FIr RST:$reg)>;
+</pre>
+</div>
+
+
+<p>Instruction aliases can also have a Requires clause to make them
+subtarget specific.</p>
+
+<p>If the back-end supports it, the instruction printer can automatically emit
+ the alias rather than what's being aliased. It typically leads to better,
+ more readable code. If it's better to print out what's being aliased, then
+ pass a '0' as the third parameter to the InstAlias definition.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3 id="na_matching">Instruction Matching</h3>
+
+<div><p>To Be Written</p></div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="targetimpls">Target-specific Implementation Notes</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>This section of the document explains features or design decisions that are
+ specific to the code generator for a particular target. First we start
+ with a table that summarizes what features are supported by each target.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetfeatures">Target Feature Matrix</a>
+</h3>
+
+<div>
+
+<p>Note that this table does not include the C backend or Cpp backends, since
+they do not use the target independent code generator infrastructure. It also
+doesn't list features that are not supported fully by any target yet. It
+considers a feature to be supported if at least one subtarget supports it. A
+feature being supported means that it is useful and works for most cases, it
+does not indicate that there are zero known bugs in the implementation. Here
+is the key:</p>
+
+
+<table border="1" cellspacing="0">
+ <tr>
+ <th>Unknown</th>
+ <th>No support</th>
+ <th>Partial Support</th>
+ <th>Complete Support</th>
+ </tr>
+ <tr>
+ <td class="unknown"></td>
+ <td class="no"></td>
+ <td class="partial"></td>
+ <td class="yes"></td>
+ </tr>
+</table>
+
+<p>Here is the table:</p>
+
+<table width="689" border="1" cellspacing="0">
+<tr><td></td>
+<td colspan="13" align="center" style="background-color:#ffc">Target</td>
+</tr>
+ <tr>
+ <th>Feature</th>
+ <th>ARM</th>
+ <th>Alpha</th>
+ <th>Blackfin</th>
+ <th>CellSPU</th>
+ <th>MBlaze</th>
+ <th>MSP430</th>
+ <th>Mips</th>
+ <th>PTX</th>
+ <th>PowerPC</th>
+ <th>Sparc</th>
+ <th>SystemZ</th>
+ <th>X86</th>
+ <th>XCore</th>
+ </tr>
+
+<tr>
+ <td><a href="#feat_reliable">is generally reliable</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="unknown"></td> <!-- Alpha -->
+ <td class="no"></td> <!-- Blackfin -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="yes"></td> <!-- Sparc -->
+ <td class="unknown"></td> <!-- SystemZ -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_asmparser">assembly parser</a></td>
+ <td class="no"></td> <!-- ARM -->
+ <td class="no"></td> <!-- Alpha -->
+ <td class="no"></td> <!-- Blackfin -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="no"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="no"></td> <!-- PowerPC -->
+ <td class="no"></td> <!-- Sparc -->
+ <td class="no"></td> <!-- SystemZ -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="no"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_disassembler">disassembler</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="no"></td> <!-- Alpha -->
+ <td class="no"></td> <!-- Blackfin -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="no"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="no"></td> <!-- PowerPC -->
+ <td class="no"></td> <!-- Sparc -->
+ <td class="no"></td> <!-- SystemZ -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="no"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_inlineasm">inline asm</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="unknown"></td> <!-- Alpha -->
+ <td class="yes"></td> <!-- Blackfin -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="unknown"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="unknown"></td> <!-- Sparc -->
+ <td class="unknown"></td> <!-- SystemZ -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_jit">jit</a></td>
+ <td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->
+ <td class="no"></td> <!-- Alpha -->
+ <td class="no"></td> <!-- Blackfin -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="unknown"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="unknown"></td> <!-- Sparc -->
+ <td class="unknown"></td> <!-- SystemZ -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_objectwrite">.o file writing</a></td>
+ <td class="no"></td> <!-- ARM -->
+ <td class="no"></td> <!-- Alpha -->
+ <td class="no"></td> <!-- Blackfin -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="no"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="no"></td> <!-- PowerPC -->
+ <td class="no"></td> <!-- Sparc -->
+ <td class="no"></td> <!-- SystemZ -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="no"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_tailcall">tail calls</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="unknown"></td> <!-- Alpha -->
+ <td class="no"></td> <!-- Blackfin -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="unknown"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="unknown"></td> <!-- Sparc -->
+ <td class="unknown"></td> <!-- SystemZ -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+
+</table>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_reliable">Is Generally Reliable</h4>
+
+<div>
+<p>This box indicates whether the target is considered to be production quality.
+This indicates that the target has been used as a static compiler to
+compile large amounts of code by a variety of different people and is in
+continuous use.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_asmparser">Assembly Parser</h4>
+
+<div>
+<p>This box indicates whether the target supports parsing target specific .s
+files by implementing the MCAsmParser interface. This is required for llvm-mc
+to be able to act as a native assembler and is required for inline assembly
+support in the native .o file writer.</p>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_disassembler">Disassembler</h4>
+
+<div>
+<p>This box indicates whether the target supports the MCDisassembler API for
+disassembling machine opcode bytes into MCInst's.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_inlineasm">Inline Asm</h4>
+
+<div>
+<p>This box indicates whether the target supports most popular inline assembly
+constraints and modifiers.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_jit">JIT Support</h4>
+
+<div>
+<p>This box indicates whether the target supports the JIT compiler through
+the ExecutionEngine interface.</p>
+
+<p id="feat_jit_arm">The ARM backend has basic support for integer code
+in ARM codegen mode, but lacks NEON and full Thumb support.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_objectwrite">.o File Writing</h4>
+
+<div>
+
+<p>This box indicates whether the target supports writing .o files (e.g. MachO,
+ELF, and/or COFF) files directly from the target. Note that the target also
+must include an assembly parser and general inline assembly support for full
+inline assembly support in the .o writer.</p>
+
+<p>Targets that don't support this feature can obviously still write out .o
+files, they just rely on having an external assembler to translate from a .s
+file to a .o file (as is the case for many C compilers).</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_tailcall">Tail Calls</h4>
+
+<div>
+
+<p>This box indicates whether the target supports guaranteed tail calls. These
+are calls marked "<a href="LangRef.html#i_call">tail</a>" and use the fastcc
+calling convention. Please see the <a href="#tailcallopt">tail call section
+more more details</a>.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="tailcallopt">Tail call optimization</a>
+</h3>
+
+<div>
+
+<p>Tail call optimization, callee reusing the stack of the caller, is currently
+ supported on x86/x86-64 and PowerPC. It is performed if:</p>
+
+<ul>
+ <li>Caller and callee have the calling convention <tt>fastcc</tt> or
+ <tt>cc 10</tt> (GHC call convention).</li>
+
+ <li>The call is a tail call - in tail position (ret immediately follows call
+ and ret uses value of call or is void).</li>
+
+ <li>Option <tt>-tailcallopt</tt> is enabled.</li>
+
+ <li>Platform specific constraints are met.</li>
+</ul>
+
+<p>x86/x86-64 constraints:</p>
+
+<ul>
+ <li>No variable argument lists are used.</li>
+
+ <li>On x86-64 when generating GOT/PIC code only module-local calls (visibility
+ = hidden or protected) are supported.</li>
+</ul>
+
+<p>PowerPC constraints:</p>
+
+<ul>
+ <li>No variable argument lists are used.</li>
+
+ <li>No byval parameters are used.</li>
+
+ <li>On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected) are supported.</li>
+</ul>
+
+<p>Example:</p>
+
+<p>Call as <tt>llc -tailcallopt test.ll</tt>.</p>
+
+<div class="doc_code">
+<pre>
+declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
+
+define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
+ %l1 = add i32 %in1, %in2
+ %tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
+ ret i32 %tmp
+}
+</pre>
+</div>
+
+<p>Implications of <tt>-tailcallopt</tt>:</p>
+
+<p>To support tail call optimization in situations where the callee has more
+ arguments than the caller a 'callee pops arguments' convention is used. This
+ currently causes each <tt>fastcc</tt> call that is not tail call optimized
+ (because one or more of above constraints are not met) to be followed by a
+ readjustment of the stack. So performance might be worse in such cases.</p>
+
+</div>
+<!-- ======================================================================= -->
+<h3>
+ <a name="sibcallopt">Sibling call optimization</a>
+</h3>
+
+<div>
+
+<p>Sibling call optimization is a restricted form of tail call optimization.
+ Unlike tail call optimization described in the previous section, it can be
+ performed automatically on any tail calls when <tt>-tailcallopt</tt> option
+ is not specified.</p>
+
+<p>Sibling call optimization is currently performed on x86/x86-64 when the
+ following constraints are met:</p>
+