projects / oota-llvm.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Add encoding for VSTR.
[oota-llvm.git] / docs / CodeGenerator.html
diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html
index 3a494b49f39e725cdebd65ede8405b8a638d2d46..f83d7b0e3133c819de25791706fd431b977fbe96 100644 (file)
--- a/docs/CodeGenerator.html
+++ b/docs/CodeGenerator.html
@@ -5,6 +5,17 @@
   <meta http-equiv="content-type" content="text/html; charset=utf-8">
   <title>The LLVM Target-Independent Code Generator</title>
   <link rel="stylesheet" href="llvm.css" type="text/css">
+
+  <style type="text/css">
+    .unknown { background-color: #C0C0C0; text-align: center; }
+    .unknown:before { content: "?" }
+    .no { background-color: #C11B17 }
+    .no:before { content: "N" }
+    .partial { background-color: #F88017 }
+    .yes { background-color: #0F0; }
+    .yes:before { content: "Y" }
+  </style>
+
 </head>
 <body>
 
@@ -872,7 +883,7 @@ directive in a .s file).
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="mcinst">The <tt>MCInst</tt> class</a></li>
+  <a name="mcinst">The <tt>MCInst</tt> class</a>
 </div>
 
 <div class="doc_text">
@@ -1878,15 +1889,78 @@ We've tried hard to automate the generation of the assembler from the .td files
 part of the manual and repetitive data entry can be factored and shared with the
 compiler.</p>
 
+</div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection" id="na_instparsing">Instruction Parsing</div>
 
-</div>
+<div class="doc_text"><p>To Be Written</p></div>
 
 
 <!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="proepicode">Prolog/Epilog Code Insertion</a>
+<div class="doc_subsection" id="na_instaliases">
+  Instruction Alias Processing
+</div>
+
+<div class="doc_text">
+<p>Once the instruction is parsed, it enters the MatchInstructionImpl function.
+The MatchInstructionImpl function performs alias processing and then does
+actual matching.</p>
+
+<p>Alias processing is the phase that canonicalizes different lexical forms of
+the same instructions down to one representation.  There are several different
+kinds of alias that are possible to implement and they are listed below in the
+order that they are processed (which is in order from simplest/weakest to most
+complex/powerful).  Generally you want to use the first alias mechanism that
+meets the needs of your instruction, because it will allow a more concise
+description.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">Mnemonic Aliases</div>
+
+<div class="doc_text">
+
+<p>The first phase of alias processing is simple instruction mnemonic
+remapping for classes of instructions which are allowed with two different
+mnemonics.  This phase is a simple and unconditionally remapping from one input
+mnemonic to one output mnemonic.  It isn't possible for this form of alias to
+look at the operands at all, so the remapping must apply for all forms of a
+given mnemonic.  Mnemonic aliases are defined simply, for example X86 has:
+</p>
+
+<div class="doc_code">
+<pre>
+def : MnemonicAlias&lt;"cbw",     "cbtw"&gt;;
+def : MnemonicAlias&lt;"smovq",   "movsq"&gt;;
+def : MnemonicAlias&lt;"fldcww",  "fldcw"&gt;;
+def : MnemonicAlias&lt;"fucompi", "fucomip"&gt;;
+def : MnemonicAlias&lt;"ud2a",    "ud2"&gt;;
+</pre>
 </div>
+
+<p>... and many others.  With a MnemonicAlias definition, the mnemonic is
+remapped simply and directly.  Though MnemonicAlias's can't look at any aspect
+of the instruction (such as the operands) they can depend on global modes (the
+same ones supported by the matcher), through a Requires clause:</p>
+
+<div class="doc_code">
+<pre>
+def : MnemonicAlias&lt;"pushf", "pushfq"&gt;, Requires&lt;[In64BitMode]&gt;;
+def : MnemonicAlias&lt;"pushf", "pushfl"&gt;, Requires&lt;[In32BitMode]&gt;;
+</pre>
+</div>
+
+<p>In this example, the mnemonic gets mapped into different a new one depending
+on the current instruction set.</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<div class="doc_subsection" id="na_matching">Instruction Matching</div>
+
 <div class="doc_text"><p>To Be Written</p></div>
 
 
@@ -1911,17 +1985,6 @@ compiler.</p>
   <a name="targetfeatures">Target Feature Matrix</a>
 </div>
 
-<style type="text/css">
-  .unknown { background-color: #C0C0C0; text-align: center; }
-  .unknown:before { content: "?" }
-  .no { background-color: #C11B17 }
-  .no:before { content: "N" }
-  .partial { background-color: #F88017 }
-  .yes { background-color: #00FF00; }
-  .yes:before { content: "Y" }
-</style>
-
-
 <div class="doc_text">
 
 <p>Note that this table does not include the C backend or Cpp backends, since
@@ -1952,7 +2015,7 @@ is the key:</p>
 
 <table width="689" border="1" cellspacing="0">
 <tr><td></td>
-<td colspan="13" align="center" bgcolor="#ffffcc">Target</td>
+<td colspan="13" align="center" style="background-color:#ffc">Target</td>
 </tr>
   <tr>
     <th>Feature</th>
@@ -1975,8 +2038,8 @@ is the key:</p>
   <td><a href="#feat_reliable">is generally reliable</a></td>
   <td class="yes"></td> <!-- ARM -->
   <td class="unknown"></td> <!-- Alpha -->
-  <td class="unknown"></td> <!-- Blackfin -->
-  <td class="unknown"></td> <!-- CellSPU -->
+  <td class="no"></td> <!-- Blackfin -->
+  <td class="no"></td> <!-- CellSPU -->
   <td class="no"></td> <!-- MBlaze -->
   <td class="unknown"></td> <!-- MSP430 -->
   <td class="unknown"></td> <!-- Mips -->
@@ -2026,8 +2089,8 @@ is the key:</p>
   <td><a href="#feat_inlineasm">inline asm</a></td>
   <td class="yes"></td> <!-- ARM -->
   <td class="unknown"></td> <!-- Alpha -->
-  <td class="unknown"></td> <!-- Blackfin -->
-  <td class="unknown"></td> <!-- CellSPU -->
+  <td class="yes"></td> <!-- Blackfin -->
+  <td class="no"></td> <!-- CellSPU -->
   <td class="no"></td> <!-- MBlaze -->
   <td class="unknown"></td> <!-- MSP430 -->
   <td class="unknown"></td> <!-- Mips -->
@@ -2043,8 +2106,8 @@ is the key:</p>
   <td><a href="#feat_jit">jit</a></td>
   <td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->
   <td class="unknown"></td> <!-- Alpha -->
-  <td class="unknown"></td> <!-- Blackfin -->
-  <td class="unknown"></td> <!-- CellSPU -->
+  <td class="no"></td> <!-- Blackfin -->
+  <td class="no"></td> <!-- CellSPU -->
   <td class="no"></td> <!-- MBlaze -->
   <td class="unknown"></td> <!-- MSP430 -->
   <td class="unknown"></td> <!-- Mips -->
@@ -2077,8 +2140,8 @@ is the key:</p>
   <td><a href="#feat_tailcall">tail calls</a></td>
   <td class="yes"></td> <!-- ARM -->
   <td class="unknown"></td> <!-- Alpha -->
-  <td class="unknown"></td> <!-- Blackfin -->
-  <td class="unknown"></td> <!-- CellSPU -->
+  <td class="no"></td> <!-- Blackfin -->
+  <td class="no"></td> <!-- CellSPU -->
   <td class="no"></td> <!-- MBlaze -->
   <td class="unknown"></td> <!-- MSP430 -->
   <td class="unknown"></td> <!-- Mips -->
@@ -2160,6 +2223,10 @@ 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>
 
 <!-- _______________________________________________________________________ -->
C/C++ LLVM-based compilers that forbids OOTA behaviors