"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
+ <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">
</head>
<li><a href="#targetimpls">Target-specific Implementation Notes</a>
<ul>
<li><a href="#x86">The X86 backend</a></li>
- <li><a href="#ppc">The PowerPC backend</a></li>
+ <li><a href="#ppc">The PowerPC backend</a>
<ul>
<li><a href="#ppc_abi">LLVM PowerPC ABI</a></li>
<li><a href="#ppc_frame">Frame Layout</a></li>
<li><a href="#ppc_prolog">Prolog/Epilog</a></li>
<li><a href="#ppc_dynamic">Dynamic Allocation</a></li>
- </ul>
- </ul>
- </li>
+ </ul></li>
+ </ul></li>
</ol>
<div class="doc_author">
<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a>,
- <a href="mailto:isanbard@gmail.com">Bill Wendling</a>, and
+ <a href="mailto:isanbard@gmail.com">Bill Wendling</a>,
<a href="mailto:pronesto@gmail.com">Fernando Magno Quintao
- Pereira</a></p>
+ Pereira</a> and
+ <a href="mailto:jlaskey@mac.com">Jim Laskey</a></p>
</div>
<div class="doc_warning">
<li>the type to use for shift amounts</li>
<li>various high-level characteristics, like whether it is profitable to turn
division by a constant into a multiplication sequence</li>
-</ol>
+</ul>
</div>
<p>
Instruction Selection is the process of translating LLVM code presented to the
code generator into target-specific machine instructions. There are several
-well-known ways to do this in the literature. In LLVM there are two main forms:
-the SelectionDAG based instruction selector framework and an old-style 'simple'
-instruction selector, which effectively peephole selects each LLVM instruction
-into a series of machine instructions. We recommend that all targets use the
-SelectionDAG infrastructure.
+well-known ways to do this in the literature. LLVM uses a SelectionDAG based
+instruction selector.
</p>
<p>Portions of the DAG instruction selector are generated from the target
description (<tt>*.td</tt>) files. Our goal is for the entire instruction
-selector to be generated from these <tt>.td</tt> files.</p>
+selector to be generated from these <tt>.td</tt> files, though currently
+there are still things that require custom C++ code.</p>
</div>
<!-- _______________________________________________________________________ -->
this, you probably <a href="ProgrammersManual.html#ViewGraph">need to configure
your system</a> to add support for it). The <tt>-view-sched-dags</tt> option
views the SelectionDAG output from the Select phase and input to the Scheduler
-phase.</p>
+phase. The <tt>-view-sunit-dags</tt> option views the ScheduleDAG, which is
+based on the final SelectionDAG, with nodes that must be scheduled as a unit
+bundled together into a single node, and with immediate operands and other
+nodes that aren't relevent for scheduling omitted.
+</p>
</div>
<li>There is no great way to support matching complex addressing modes yet. In
the future, we will extend pattern fragments to allow them to define
multiple values (e.g. the four operands of the <a href="#x86_memory">X86
- addressing mode</a>). In addition, we'll extend fragments so that a
+ addressing mode</a>, which are currently matched with custom C++ code).
+ In addition, we'll extend fragments so that a
fragment can match multiple different patterns.</li>
<li>We don't automatically infer flags like isStore/isLoad yet.</li>
<li>We don't automatically generate the set of supported registers and
- operations for the <a href="#"selectiondag_legalize>Legalizer</a> yet.</li>
+ operations for the <a href="#selectiondag_legalize">Legalizer</a> yet.</li>
<li>We don't have a way of tying in custom legalized nodes yet.</li>
</ul>
<ol>
<li>Optional function-at-a-time selection.</li>
<li>Auto-generate entire selector from <tt>.td</tt> file.</li>
-</li>
</ol>
</div>
<p><i><b>More to come...</b></i></p>
-</ol>
-
</div>
<!-- ======================================================================= -->
<div class="doc_code">
<pre>
-bool RegMapping_Fer::compatible_class(MachineFunction &mf,
+bool RegMapping_Fer::compatible_class(MachineFunction &mf,
unsigned v_reg,
unsigned p_reg) {
- assert(MRegisterInfo::isPhysicalRegister(p_reg) &&
+ assert(MRegisterInfo::isPhysicalRegister(p_reg) &&
"Target register must be physical");
const TargetRegisterClass *trc = mf.getSSARegMap()->getRegClass(v_reg);
return trc->contains(p_reg);
<tt>MachineOperand::isDef()</tt> informs if that registers is being
defined.</p>
-<p>We will call physical registers present in the LLVM bytecode before
+<p>We will call physical registers present in the LLVM bitcode before
register allocation <i>pre-colored registers</i>. Pre-colored
registers are used in many different situations, for instance, to pass
parameters of functions calls, and to store results of particular
<div class="doc_text">
<p>The X86 code generator lives in the <tt>lib/Target/X86</tt> directory. This
-code generator currently targets a generic P6-like processor. As such, it
-produces a few P6-and-above instructions (like conditional moves), but it does
-not make use of newer features like MMX or SSE. In the future, the X86 backend
-will have sub-target support added for specific processor families and
-implementations.</p>
+code generator is capable of targeting a variety of x86-32 and x86-64
+processors, and includes support for ISA extensions such as MMX and SSE.
+</p>
</div>
is used. Second, r31 is used as a frame pointer to allow dynamic growth of a
stack frame. LLVM takes advantage of having no TOC to provide space to save
the frame pointer in the PowerPC linkage area of the caller frame. Other
-details of PowerPC ABI can be found at <a
-href="http://developer.apple.com/documentation/DeveloperTools/Conceptual/
-LowLevelABI/Articles/32bitPowerPC.html" target="_blank">PowerPC ABI.</a> Note:
-This link describes the 32 bit ABI. The 64 bit ABI is similar except space for
-GPRs are 8 bytes wide (not 4) and r13 is reserved for system use.</p>
+details of PowerPC ABI can be found at <a href=
+"http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html"
+>PowerPC ABI.</a> Note: This link describes the 32 bit ABI. The
+64 bit ABI is similar except space for GPRs are 8 bytes wide (not 4) and r13 is
+reserved for system use.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_text">
<p>The size of a PowerPC frame is usually fixed for the duration of a
-function's invocation. Since the frame is fixed size, all references into
+function’s invocation. Since the frame is fixed size, all references into
the frame can be accessed via fixed offsets from the stack pointer. The
exception to this is when dynamic alloca or variable sized arrays are present,
then a base pointer (r31) is used as a proxy for the stack pointer and stack
<p></p>
</div>
-<i>TODO - More to come.</i>
+<div class="doc_text">
+<p><i>TODO - More to come.</i></p>
+</div>
<!-- *********************************************************************** -->
projects / oota-llvm.git / blobdiff