6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-13 04:30:23 +00:00
Code Issues Projects Releases Wiki Activity

Add some initial documentation for the SelectionDAG based instruction selectors

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@19872 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2005-01-28 17:22:53 +00:00
parent e6585ab601
commit aa5bcb526b
1 changed files with 331 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

345
docs/CodeGenerator.html
View File

@ -23,6 +23,7 @@
<ul>
<li><a href="#targetmachine">The <tt>TargetMachine</tt> class</a></li>
<li><a href="#targetdata">The <tt>TargetData</tt> class</a></li>
<li><a href="#targetlowering">The <tt>TargetLowering</tt> class</a></li>
<li><a href="#mregisterinfo">The <tt>MRegisterInfo</tt> class</a></li>
<li><a href="#targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a></li>
<li><a href="#targetframeinfo">The <tt>TargetFrameInfo</tt> class</a></li>
@ -31,14 +32,30 @@
</li>
<li><a href="#codegendesc">Machine code description classes</a>
<ul>
<li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
<li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
</ul>
</li>
<li><a href="#codegenalgs">Target-independent code generation algorithms</a>
<ul>
<li><a href="#instselect">Instruction Selection</a>
<ul>
<li><a href="#selectiondag_intro">Introduction to SelectionDAGs</a></li>
<li><a href="#selectiondag_process">SelectionDAG Code Generation
Process</a></li>
<li><a href="#selectiondag_build">Initial SelectionDAG
Construction</a></li>
<li><a href="#selectiondag_legalize">SelectionDAG Legalize Phase</a></li>
<li><a href="#selectiondag_optimize">SelectionDAG Optimization
Phase</a></li>
<li><a href="#selectiondag_select">SelectionDAG Select Phase</a></li>
<li><a href="#selectiondag_future">Future directions for the
SelectionDAG</a></li>
</ul></li>
</ul>
</li>
<li><a href="#targetimpls">Target description implementations</a>
<ul>
<li><a href="#x86">The X86 backend</a></li>
<li><a href="#x86">The X86 backend</a></li>
</ul>
</li>
@ -159,16 +176,17 @@ predictable completion date.</p>
<div class="doc_text">
<p>The LLVM target-indendent code generator is designed to support efficient and
<p>The LLVM target-independent code generator is designed to support efficient and
quality code generation for standard register-based microprocessors. Code
generation in this model is divided into the following stages:</p>
<ol>
<li><b>Instruction Selection</b> - Determining an efficient implementation of the
input LLVM code in the target instruction set. This stage produces the initial
code for the program in the target instruction set, then makes use of virtual
registers in SSA form and physical registers that represent any required
register assignments due to target constraints or calling conventions.</li>
<li><b><a href="#instselect">Instruction Selection</a></b> - Determining an
efficient implementation of the input LLVM code in the target instruction set.
This stage produces the initial code for the program in the target instruction
set, then makes use of virtual registers in SSA form and physical registers that
represent any required register assignments due to target constraints or calling
conventions.</li>
<li><b>SSA-based Machine Code Optimizations</b> - This (optional) stage consists
of a series of machine-code optimizations that operate on the SSA-form produced
@ -205,7 +223,7 @@ expansion and
aggressive iterative peephole optimization are much slower. This design
permits efficient compilation (important for JIT environments) and
aggressive optimization (used when generating code offline) by allowing
components of varying levels of sophisication to be used for any step of
components of varying levels of sophistication to be used for any step of
compilation.</p>
<p>
@ -296,6 +314,25 @@ target, and whether the target is little- or big-endian.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="targetlowering">The <tt>TargetLowering</tt> class</a>
</div>
<div class="doc_text">
<p>The <tt>TargetLowering</tt> class is used by SelectionDAG based instruction
selectors primarily to describe how LLVM code should be lowered to SelectionDAG
operations. Among other things, this class indicates an initial register class
to use for various ValueTypes, which operations are natively supported by the
target machine, and some other miscellaneous properties (such as the return type
of setcc operations, the type to use for shift amounts, etc).</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
@ -384,8 +421,8 @@ an opcode number and some number of operands.</p>
<p>The opcode number is an simple unsigned number that only has meaning to a
specific backend. All of the instructions for a target should be defined in
the <tt>*InstrInfo.td</tt> file for the target, and the opcode enum values
are autogenerated from this description. The <tt>MachineInstr</tt> class does
not have any information about how to intepret the instruction (i.e., what the
are auto-generated from this description. The <tt>MachineInstr</tt> class does
not have any information about how to interpret the instruction (i.e., what the
semantics of the instruction are): for that you must refer to the
<tt><a href="#targetinstrinfo">TargetInstrInfo</a></tt> class.</p>
@ -396,7 +433,7 @@ In addition, a machine operand should be marked as a def or a use of the value
<p>By convention, the LLVM code generator orders instruction operands so that
all register definitions come before the register uses, even on architectures
that are normally printed in other orders. For example, the sparc add
that are normally printed in other orders. For example, the SPARC add
instruction: "<tt>add %i1, %i2, %i3</tt>" adds the "%i1", and "%i2" registers
and stores the result into the "%i3" register. In the LLVM code generator,
the operands should be stored as "<tt>%i3, %i1, %i2</tt>": with the destination
@ -503,7 +540,7 @@ and ret (use
ret
</pre>
<p>By the end of code generation, the register allocator has coallesced
<p>By the end of code generation, the register allocator has coalesced
the registers and deleted the resultant identity moves, producing the
following code:</p>
@ -544,6 +581,286 @@ are no virtual registers left in the code.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="codegenalgs">Target-independent code generation algorithms</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>This section documents the phases described in the <a
href="high-level-design">high-level design of the code generator</a>. It
explains how they work and some of the rationale behind their design.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="instselect">Instruction Selection</a>
</div>
<div class="doc_text">
<p>
Instruction Selection is the process of translating the LLVM code input 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 old-style 'simple' instruction selector (which effectively peephole selects
each LLVM instruction into a series of machine instructions), and the new
SelectionDAG based instruction selector.
</p>
<p>The 'simple' instruction selectors are tedious to write, require a lot of
boiler plate code, and are difficult to get correct. Additionally, any
optimizations written for a simple instruction selector cannot be used by other
targets. For this reason, LLVM is moving to a new SelectionDAG based
instruction selector, which is described in this section. If you are starting a
new port, we recommend that you write the instruction selector using the
SelectionDAG infrastructure.</p>
<p>In time, most of the target-specific code for instruction selection will be
auto-generated from the target .td files. For now, however, the <a
href="#selectiondag_select">Select Phase</a> must still be written by hand.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="selectiondag_intro">Introduction to SelectionDAGs</a>
</div>
<div class="doc_text">
<p>
The SelectionDAG provides an abstraction for representing code in a way that is
amenable to instruction selection using automatic techniques
(e.g. dynamic-programming based optimal pattern matching selectors), as well as
an abstraction that is useful for other phases of code generation (in
particular, instruction scheduling). Additionally, the SelectionDAG provides a
host representation where a large variety of very-low-level (but
target-independent) <a href="#selectiondag_optimize">optimizations</a> may be
performed: ones which require extensive information about the instructions
efficiently supported by the target.
</p>
<p>
The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
<tt>SDNode</tt> class. The primary payload of the Node is its operation code
(Opcode) that indicates what the operation the node performs. The various
operation node types are described at the top of the
<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt> file. Depending on the operation, nodes may contain additional information (e.g. the condition code
for a SETCC node) contained in a derived class.</p>
<p>Each node in the graph may define multiple values
(e.g. for a combined div/rem operation and many other situations), though most
operations define a single value. Each node also has some number of operands,
which are edges to the node defining the used value. Because nodes may define
multiple values, edges are represented by instances of the <tt>SDOperand</tt>
class, which is a &lt;SDNode, unsigned&gt; pair, indicating the node and result
value being used. Each value produced by a SDNode has an associated
MVT::ValueType, indicating what type the value is.
</p>
<p>
SelectionDAGs contain two different kinds of value: those that represent data
flow and those that represent control flow dependencies. Data values are simple
edges with a integer or floating point value type. Control edges are
represented as "chain" edges which are of type MVT::Other. These edges provide
an ordering between nodes that have side effects (such as
loads/stores/calls/return/etc). All nodes that have side effects should take a
token chain as input and produce a new one as output. By convention, token
chain inputs are always operand #0, and chain results are always the last
value produced by an operation.</p>
<p>
A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
always a marker node with Opcode of ISD::TokenFactor. The Root node is the
final side effecting node in the token chain (for example, in a single basic
block function, this would be the return node).
</p>
<p>
One important concept for SelectionDAGs is the notion of a "legal" vs "illegal"
DAG. A legal DAG for a target is one that only uses supported operations and
supported types. On PowerPC, for example, a DAG with any values of i1, i8, i16,
or i64 type would be illegal. The <a href="#selectiondag_legalize">legalize</a>
phase is the one responsible for turning an illegal DAG into a legal DAG.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="selectiondag_process">SelectionDAG Code Generation Process</a>
</div>
<div class="doc_text">
<p>
SelectionDAG-based instruction selection consists of the following steps:
</p>
<ol>
<li><a href="#selectiondag_build">Build initial DAG</a> - This stage performs
a simple translation from the input LLVM code to an illegal SelectionDAG.
</li>
<li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> - This stage
performs simple optimizations on the SelectionDAG to simplify it and
recognize meta instructions (like rotates and div/rem pairs) for
targets that support these meta operations. This makes the resultant code
more efficient and the 'select' phase more simple.
</li>
<li><a href="#selectiondag_legalize">Legalize SelectionDAG</a> - This stage
converts the illegal SelectionDAG to a legal SelectionDAG, by eliminating
unsupported operations and data types.</li>
<li><a href="#selectiondag_optimize">Optimize SelectionDAG (#2)</a> - This
second run of the SelectionDAG optimized the newly legalized DAG, to
eliminate inefficiencies introduced by legalization.</li>
<li><a href="#selectiondag_select">Select instructions from DAG</a> - Finally,
the target instruction selector matches the DAG operations to target
instructions, emitting them and building the MachineFunction being
compiled.</li>
</ol>
<p>After all of these steps are complete, the SelectionDAG is destroyed and the
rest of the code generation passes are run.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="selectiondag_build">Initial SelectionDAG Construction</a>
</div>
<div class="doc_text">
<p>
The initial SelectionDAG is naively peephole expanded from the LLVM input by
the SelectionDAGLowering class in the SelectionDAGISel.cpp file. The idea of
doing this pass is to expose as much low-level target-specific details to the
SelectionDAG as possible. This pass is mostly hard-coded (e.g. an LLVM add
turns into a SDNode add, a geteelementptr is expanded into the obvious
arithmetic, etc) but does require target-specific hooks to lower calls and
returns, varargs, etc. For these features, the TargetLowering interface is
used.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="selectiondag_legalize">SelectionDAG Legalize Phase</a>
</div>
<div class="doc_text">
<p>The Legalize phase is in charge of converting a DAG to only use the types and
operations that are natively supported by the target. This involves two major
tasks:</p>
<ol>
<li><p>Convert values of unsupported types to values of supported types.</p>
<p>There are two main ways of doing this: promoting a small type to a larger
type (e.g. f32 -> f64, or i16 -> i32), and expanding larger integer types
to smaller ones (e.g. implementing i64 with i32 operations where
possible). Promotion insert sign and zero extensions as needed to make
sure that the final code has the same behavior as the input.</p>
</li>
<li><p>Eliminate operations that are not supported by the target in a supported
type.</p>
<p>Targets often have wierd constraints, such as not supporting every
operation on every supported datatype (e.g. X86 does not support byte
conditional moves). Legalize takes care of either open-coding another
sequence of operations to emulate the operation (this is known as
expansion), promoting to a larger type that supports the operation
(promotion), or can use a target-specific hook to implement the
legalization.</p>
</li>
</ol>
<p>
Instead of using a Legalize pass, we could require that every target-specific
<a href="#selectiondag_optimize">selector</a> support and expand every operator
and type even if they are not supported and may require many instructions to
implement (in fact, this is the approach taken by the "simple" selectors).
However, using a Legalize pass allows all of the cannonicalization patterns to
be shared across targets, and makes it very easy to optimize the cannonicalized
code (because it is still in the form of a DAG).
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="selectiondag_optimize">SelectionDAG Optimization Phase</a>
</div>
<div class="doc_text">
<p>
The SelectionDAG optimization phase is run twice for code generation: once
immediately after the DAG is built and once after legalization. The first pass
allows the initial code to be cleaned up, (for example) performing optimizations
that depend on knowing that the operators have restricted type inputs. The second
pass cleans up the messy code generated by the Legalize pass, allowing Legalize to
be very simple (not having to take into account many special cases.
</p>
<p>
One important class of optimizations that this pass will do in the future is
optimizing inserted sign and zero extension instructions. Here are some good
papers on the subject:</p>
<p>
"<a href="http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html">Widening
integer arithmetic</a>"<br>
Kevin Redwine and Norman Ramsey<br>
International Conference on Compiler Construction (CC) 2004
</p>
<p>
"<a href="http://portal.acm.org/citation.cfm?doid=512529.512552">Effective
sign extension elimination</a>"<br>
Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani<br>
Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
and Implementation.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="selectiondag_select">SelectionDAG Select Phase</a>
</div>
<div class="doc_text">
<p>The Select phase is the bulk of the target-specific code for instruction
selection. This phase takes a legal SelectionDAG as input, and does simple
pattern matching on the DAG to generate code. In time, the Select phase will
be automatically generated from the targets InstrInfo.td file, which is why we
want to make the Select phase a simple and mechanical as possible.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="selectiondag_future">Future directions for the SelectionDAG</a>
</div>
<div class="doc_text">
<ol>
<li>Optional whole-function selection.</li>
<li>Select is a graph translation phase.</li>
<li>Place the machine instrs resulting from Select according to register pressure or a schedule.</li>
<li>DAG Scheduling.</li>
<li>Auto-generate the Select phase from the target .td files.</li>
</ol>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="targetimpls">Target description implementations</a>
@ -570,7 +887,7 @@ 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 subtarget support added for specific processor families and
will have sub-target support added for specific processor families and
implementations.</p>
</div>