projects
/
oota-llvm.git
/ blobdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
|
commitdiff
|
tree
raw
|
inline
| side by side
Common symbols are not undefined, at least for ObjectFile.
[oota-llvm.git]
/
docs
/
CodeGenerator.rst
diff --git
a/docs/CodeGenerator.rst
b/docs/CodeGenerator.rst
index d7d98bc385be66a86c3c65b460403ddd740dc7d0..516031dd7bccbb041822488f1f6a61ff8661a9be 100644
(file)
--- a/
docs/CodeGenerator.rst
+++ b/
docs/CodeGenerator.rst
@@
-70,7
+70,7
@@
different pieces of this will be useful to you. In any case, you should be
familiar with the `target description`_ and `machine code representation`_
classes. If you want to add a backend for a new target, you will need to
`implement the target description`_ classes for your new target and understand
familiar with the `target description`_ and `machine code representation`_
classes. If you want to add a backend for a new target, you will need to
`implement the target description`_ classes for your new target and understand
-the
`LLVM code representation <LangRef.html>`_
. If you are interested in
+the
:doc:`LLVM code representation <LangRef>`
. If you are interested in
implementing a new `code generation algorithm`_, it should only depend on the
target-description and machine code representation classes, ensuring that it is
portable.
implementing a new `code generation algorithm`_, it should only depend on the
target-description and machine code representation classes, ensuring that it is
portable.
@@
-172,7
+172,7
@@
architecture. These target descriptions often have a large amount of common
information (e.g., an ``add`` instruction is almost identical to a ``sub``
instruction). In order to allow the maximum amount of commonality to be
factored out, the LLVM code generator uses the
information (e.g., an ``add`` instruction is almost identical to a ``sub``
instruction). In order to allow the maximum amount of commonality to be
factored out, the LLVM code generator uses the
-:doc:`TableGen
<TableGenFundamentals>
` tool to describe big chunks of the
+:doc:`TableGen
/index
` tool to describe big chunks of the
target machine, which allows the use of domain-specific and target-specific
abstractions to reduce the amount of repetition.
target machine, which allows the use of domain-specific and target-specific
abstractions to reduce the amount of repetition.
@@
-277,7
+277,7
@@
an associated register class. When the register allocator runs, it replaces
virtual registers with a physical register in the set.
The target-specific implementations of these classes is auto-generated from a
virtual registers with a physical register in the set.
The target-specific implementations of these classes is auto-generated from a
-
`TableGen <TableGenFundamentals.html>`_
description of the register file.
+
:doc:`TableGen/index`
description of the register file.
.. _TargetInstrInfo:
.. _TargetInstrInfo:
@@
-290,10
+290,10
@@
the opcode, the number of operands, the list of implicit register uses and defs,
whether the instruction has certain target-independent properties (accesses
memory, is commutable, etc), and holds any target-specific flags.
whether the instruction has certain target-independent properties (accesses
memory, is commutable, etc), and holds any target-specific flags.
-The ``TargetFrame
Info
`` class
------------------------------
+The ``TargetFrame
Lowering
`` class
+-----------------------------
----
-The ``TargetFrame
Info
`` class is used to provide information about the stack
+The ``TargetFrame
Lowering
`` class is used to provide information about the stack
frame layout of the target. It holds the direction of stack growth, the known
stack alignment on entry to each function, and the offset to the local area.
The offset to the local area is the offset from the stack pointer on function
frame layout of the target. It holds the direction of stack growth, the known
stack alignment on entry to each function, and the offset to the local area.
The offset to the local area is the offset from the stack pointer on function
@@
-464,7
+464,7
@@
code:
mov %EAX, %EDX
sar %EDX, 31
idiv %ECX
mov %EAX, %EDX
sar %EDX, 31
idiv %ECX
- ret
+ ret
This approach is extremely general (if it can handle the X86 architecture, it
can handle anything!) and allows all of the target specific knowledge about the
This approach is extremely general (if it can handle the X86 architecture, it
can handle anything!) and allows all of the target specific knowledge about the
@@
-749,7
+749,7
@@
The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
``SDNode`` class. The primary payload of the ``SDNode`` is its operation code
(Opcode) that indicates what operation the node performs and the operands to the
operation. The various operation node types are described at the top of the
``SDNode`` class. The primary payload of the ``SDNode`` is its operation code
(Opcode) that indicates what operation the node performs and the operands to the
operation. The various operation node types are described at the top of the
-``include/llvm/CodeGen/
SelectionDAGN
odes.h`` file.
+``include/llvm/CodeGen/
ISDOpc
odes.h`` file.
Although most operations define a single value, each node in the graph may
define multiple values. For example, a combined div/rem operation will define
Although most operations define a single value, each node in the graph may
define multiple values. For example, a combined div/rem operation will define
@@
-769,7
+769,9
@@
provide an ordering between nodes that have side effects (such as loads, stores,
calls, returns, 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
calls, returns, 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.
+produced by an operation. However, after instruction selection, the
+machine nodes have their chain after the instruction's operands, and
+may be followed by glue nodes.
A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
always a marker node with an Opcode of ``ISD::EntryToken``. The Root node is
A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
always a marker node with an Opcode of ``ISD::EntryToken``. The Root node is
@@
-827,7
+829,7
@@
One great way to visualize what is going on here is to take advantage of a few
LLC command line options. The following options pop up a window displaying the
SelectionDAG at specific times (if you only get errors printed to the console
while using this, you probably `need to configure your
LLC command line options. The following options pop up a window displaying the
SelectionDAG at specific times (if you only get errors printed to the console
while using this, you probably `need to configure your
-system <ProgrammersManual.html#
ViewGraph
>`_ to add support for it).
+system <ProgrammersManual.html#
viewing-graphs-while-debugging-code
>`_ to add support for it).
* ``-view-dag-combine1-dags`` displays the DAG after being built, before the
first optimization pass.
* ``-view-dag-combine1-dags`` displays the DAG after being built, before the
first optimization pass.
@@
-846,6
+848,10
@@
is based on the final SelectionDAG, with nodes that must be scheduled together
bundled into a single scheduling-unit node, and with immediate operands and
other nodes that aren't relevant for scheduling omitted.
bundled into a single scheduling-unit node, and with immediate operands and
other nodes that aren't relevant for scheduling omitted.
+The option ``-filter-view-dags`` allows to select the name of the basic block
+that you are interested to visualize and filters all the previous
+``view-*-dags`` options.
+
.. _Build initial DAG:
Initial SelectionDAG Construction
.. _Build initial DAG:
Initial SelectionDAG Construction
@@
-1228,7
+1234,7
@@
used. Each virtual register can only be mapped to physical registers of a
particular class. For instance, in the X86 architecture, some virtuals can only
be allocated to 8 bit registers. A register class is described by
``TargetRegisterClass`` objects. To discover if a virtual register is
particular class. For instance, in the X86 architecture, some virtuals can only
be allocated to 8 bit registers. A register class is described by
``TargetRegisterClass`` objects. To discover if a virtual register is
-compatible with a given physical, this code can be used:
</p>
+compatible with a given physical, this code can be used:
.. code-block:: c++
.. code-block:: c++
@@
-1334,7
+1340,7
@@
found before being stored or after being reloaded.
If the indirect strategy is used, after all the virtual registers have been
mapped to physical registers or stack slots, it is necessary to use a spiller
object to place load and store instructions in the code. Every virtual that has
If the indirect strategy is used, after all the virtual registers have been
mapped to physical registers or stack slots, it is necessary to use a spiller
object to place load and store instructions in the code. Every virtual that has
-been mapped to a stack slot will be stored to memory after be
en
defined and will
+been mapped to a stack slot will be stored to memory after be
ing
defined and will
be loaded before being used. The implementation of the spiller tries to recycle
load/store instructions, avoiding unnecessary instructions. For an example of
how to invoke the spiller, see ``RegAllocLinearScan::runOnMachineFunction`` in
be loaded before being used. The implementation of the spiller tries to recycle
load/store instructions, avoiding unnecessary instructions. For an example of
how to invoke the spiller, see ``RegAllocLinearScan::runOnMachineFunction`` in
@@
-1347,7
+1353,7
@@
With very rare exceptions (e.g., function calls), the LLVM machine code
instructions are three address instructions. That is, each instruction is
expected to define at most one register, and to use at most two registers.
However, some architectures use two address instructions. In this case, the
instructions are three address instructions. That is, each instruction is
expected to define at most one register, and to use at most two registers.
However, some architectures use two address instructions. In this case, the
-defined register is also one of the used register. For instance, an instruction
+defined register is also one of the used register
s
. For instance, an instruction
such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX +
%EBX``.
such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX +
%EBX``.
@@
-1572,7
+1578,7
@@
three important things that you have to implement for your target:
correspond to. The MCInsts that are generated by this are fed into the
instruction printer or the encoder.
correspond to. The MCInsts that are generated by this are fed into the
instruction printer or the encoder.
-Finally, at your choosing, you can also implement a
n
subclass of MCCodeEmitter
+Finally, at your choosing, you can also implement a subclass of MCCodeEmitter
which lowers MCInst's into machine code bytes and relocations. This is
important if you want to support direct .o file emission, or would like to
implement an assembler for your target.
which lowers MCInst's into machine code bytes and relocations. This is
important if you want to support direct .o file emission, or would like to
implement an assembler for your target.
@@
-1683,7
+1689,7
@@
ones supported by the matcher), through a Requires clause:
def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;
def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;
-In this example, the mnemonic gets mapped into
different a new
one depending on
+In this example, the mnemonic gets mapped into
a different
one depending on
the current instruction set.
Instruction Aliases
the current instruction set.
Instruction Aliases
@@
-1993,7
+1999,7
@@
Tail Calls
This box indicates whether the target supports guaranteed tail calls. These are
calls marked "`tail <LangRef.html#i_call>`_" and use the fastcc calling
This box indicates whether the target supports guaranteed tail calls. These are
calls marked "`tail <LangRef.html#i_call>`_" and use the fastcc calling
-convention. Please see the `tail call section
more more details`_
.
+convention. Please see the `tail call section
`_ for more details
.
.. _feat_segstacks:
.. _feat_segstacks:
@@
-2011,7
+2017,7
@@
Basic support exists on the X86 backend. Currently vararg doesn't work and the
object files are not marked the way the gold linker expects, but simple Go
programs can be built by dragonegg.
object files are not marked the way the gold linker expects, but simple Go
programs can be built by dragonegg.
-.. _tail call section
more more details
:
+.. _tail call section:
Tail call optimization
----------------------
Tail call optimization
----------------------
@@
-2027,7
+2033,7
@@
supported on x86/x86-64 and PowerPC. It is performed if:
* Option ``-tailcallopt`` is enabled.
* Option ``-tailcallopt`` is enabled.
-* Platform
specific constraints are met.
+* Platform
-
specific constraints are met.
x86/x86-64 constraints:
x86/x86-64 constraints:
@@
-2145,10
+2151,6
@@
The following target-specific calling conventions are known to backend:
others via stack. Callee is responsible for stack cleaning. This convention is
used by MSVC by default for methods in its ABI (CC ID = 70).
others via stack. Callee is responsible for stack cleaning. This convention is
used by MSVC by default for methods in its ABI (CC ID = 70).
-* **X86_CDeclMethod** --- Identical to the standard x86_32 C calling convention,
- except that an sret paramter, if present, is placed on the stack after the
- second parameter, which must an integer or pointer. (CC ID = 80).
-
.. _X86 addressing mode:
Representing X86 addressing modes in MachineInstrs
.. _X86 addressing mode:
Representing X86 addressing modes in MachineInstrs