diff options
author | Matt Beaumont-Gay <matthewbg@google.com> | 2012-12-14 17:55:15 +0000 |
---|---|---|
committer | Matt Beaumont-Gay <matthewbg@google.com> | 2012-12-14 17:55:15 +0000 |
commit | 6aed25d93d1cfcde5809a73ffa7dc1b0d6396f66 (patch) | |
tree | 57e2fdf1caf960d8d878e0289f32af6759832b49 /docs | |
parent | 7139cfb19b1cc28dfd5e274c07ec68835bc6d6d6 (diff) | |
parent | 1ad9253c9d34ccbce3e7e4ea5d87c266cbf93410 (diff) |
Updating branches/google/stable to r169803
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/google/stable@170212 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs')
88 files changed, 36742 insertions, 43431 deletions
diff --git a/docs/BitCodeFormat.rst b/docs/BitCodeFormat.rst index bd26f7b150..333e79b864 100644 --- a/docs/BitCodeFormat.rst +++ b/docs/BitCodeFormat.rst @@ -54,8 +54,8 @@ structure. This structure consists of the following concepts: * Abbreviations, which specify compression optimizations for the file. -Note that the `llvm-bcanalyzer <CommandGuide/html/llvm-bcanalyzer.html>`_ tool -can be used to dump and inspect arbitrary bitstreams, which is very useful for +Note that the :doc:`llvm-bcanalyzer <CommandGuide/llvm-bcanalyzer>` tool can be +used to dump and inspect arbitrary bitstreams, which is very useful for understanding the encoding. .. _magic number: diff --git a/docs/BranchWeightMetadata.rst b/docs/BranchWeightMetadata.rst index f0df971f87..2667ce3589 100644 --- a/docs/BranchWeightMetadata.rst +++ b/docs/BranchWeightMetadata.rst @@ -27,8 +27,8 @@ Supported Instructions ``BranchInst`` ^^^^^^^^^^^^^^ -Metadata is only assign to the conditional branches. There are two extra -operarands, for the true and the false branch. +Metadata is only assigned to the conditional branches. There are two extra +operarands for the true and the false branch. .. code-block:: llvm @@ -41,8 +41,8 @@ operarands, for the true and the false branch. ``SwitchInst`` ^^^^^^^^^^^^^^ -Branch weights are assign to every case (including ``default`` case which is -always case #0). +Branch weights are assigned to every case (including the ``default`` case which +is always case #0). .. code-block:: llvm @@ -55,7 +55,7 @@ always case #0). ``IndirectBrInst`` ^^^^^^^^^^^^^^^^^^ -Branch weights are assign to every destination. +Branch weights are assigned to every destination. .. code-block:: llvm diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst index 900fb8a81f..ce23667eb3 100644 --- a/docs/CodeGenerator.rst +++ b/docs/CodeGenerator.rst @@ -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 -`TableGen <TableGenFundamentals.html>`_ tool to describe big chunks of the +:doc:`TableGen <TableGenFundamentals>` 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. @@ -224,13 +224,13 @@ The ``DataLayout`` class ------------------------ The ``DataLayout`` class is the only required target description class, and it -is the only class that is not extensible (you cannot derived a new class from +is the only class that is not extensible (you cannot derive a new class from it). ``DataLayout`` specifies information about how the target lays out memory for structures, the alignment requirements for various data types, the size of pointers in the target, and whether the target is little-endian or big-endian. -.. _targetlowering: +.. _TargetLowering: The ``TargetLowering`` class ---------------------------- @@ -248,7 +248,9 @@ operations. Among other things, this class indicates: * the type to use for shift amounts, and * various high-level characteristics, like whether it is profitable to turn - division by a constant into a multiplication sequence + division by a constant into a multiplication sequence. + +.. _TargetRegisterInfo: The ``TargetRegisterInfo`` class -------------------------------- @@ -771,6 +773,8 @@ value of type i1, i8, i16, or i64 would be illegal, as would a DAG that uses a SREM or UREM operation. The `legalize types`_ and `legalize operations`_ phases are responsible for turning an illegal DAG into a legal DAG. +.. _SelectionDAG-Process: + SelectionDAG Instruction Selection Process ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -838,8 +842,7 @@ Initial SelectionDAG Construction ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The initial SelectionDAG is na\ :raw-html:`ï`\ vely peephole expanded from -the LLVM input by the ``SelectionDAGLowering`` class in the -``lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp`` file. The intent of this pass +the LLVM input by the ``SelectionDAGBuilder`` class. The intent of 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 an ``SDNode add`` while a ``getelementptr`` is expanded into the obvious @@ -875,7 +878,7 @@ found, the elements are converted to scalars ("scalarizing"). A target implementation tells the legalizer which types are supported (and which register class to use for them) by calling the ``addRegisterClass`` method in -its TargetLowering constructor. +its ``TargetLowering`` constructor. .. _legalize operations: .. _Legalizer: @@ -969,7 +972,8 @@ The ``FADDS`` instruction is a simple binary single-precision add instruction. To perform this pattern match, the PowerPC backend includes the following instruction definitions: -:: +.. code-block:: text + :emphasize-lines: 4-5,9 def FMADDS : AForm_1<59, 29, (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB), @@ -981,10 +985,10 @@ instruction definitions: "fadds $FRT, $FRA, $FRB", [(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))]>; -The portion of the instruction definition in bold indicates the pattern used to -match the instruction. The DAG operators (like ``fmul``/``fadd``) are defined -in the ``include/llvm/Target/TargetSelectionDAG.td`` file. " ``F4RC``" is the -register class of the input and result values. +The highlighted portion of the instruction definitions indicates the pattern +used to match the instructions. The DAG operators (like ``fmul``/``fadd``) +are defined in the ``include/llvm/Target/TargetSelectionDAG.td`` file. +"``F4RC``" is the register class of the input and result values. The TableGen DAG instruction selector generator reads the instruction patterns in the ``.td`` file and automatically builds parts of the pattern matching code @@ -1728,6 +1732,8 @@ 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. +.. _target-feature-matrix: + Target Feature Matrix --------------------- @@ -1763,7 +1769,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<th>Feature</th>` :raw-html:`<th>ARM</th>` -:raw-html:`<th>CellSPU</th>` :raw-html:`<th>Hexagon</th>` :raw-html:`<th>MBlaze</th>` :raw-html:`<th>MSP430</th>` @@ -1778,7 +1783,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a href="#feat_reliable">is generally reliable</a></td>` :raw-html:`<td class="yes"></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="yes"></td> <!-- Hexagon -->` :raw-html:`<td class="no"></td> <!-- MBlaze -->` :raw-html:`<td class="unknown"></td> <!-- MSP430 -->` @@ -1793,7 +1797,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a href="#feat_asmparser">assembly parser</a></td>` :raw-html:`<td class="no"></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="no"></td> <!-- Hexagon -->` :raw-html:`<td class="yes"></td> <!-- MBlaze -->` :raw-html:`<td class="no"></td> <!-- MSP430 -->` @@ -1808,7 +1811,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a href="#feat_disassembler">disassembler</a></td>` :raw-html:`<td class="yes"></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="no"></td> <!-- Hexagon -->` :raw-html:`<td class="yes"></td> <!-- MBlaze -->` :raw-html:`<td class="no"></td> <!-- MSP430 -->` @@ -1823,7 +1825,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a href="#feat_inlineasm">inline asm</a></td>` :raw-html:`<td class="yes"></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="yes"></td> <!-- Hexagon -->` :raw-html:`<td class="yes"></td> <!-- MBlaze -->` :raw-html:`<td class="unknown"></td> <!-- MSP430 -->` @@ -1838,7 +1839,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a href="#feat_jit">jit</a></td>` :raw-html:`<td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="no"></td> <!-- Hexagon -->` :raw-html:`<td class="no"></td> <!-- MBlaze -->` :raw-html:`<td class="unknown"></td> <!-- MSP430 -->` @@ -1853,7 +1853,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a href="#feat_objectwrite">.o file writing</a></td>` :raw-html:`<td class="no"></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="no"></td> <!-- Hexagon -->` :raw-html:`<td class="yes"></td> <!-- MBlaze -->` :raw-html:`<td class="no"></td> <!-- MSP430 -->` @@ -1868,7 +1867,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a hr:raw-html:`ef="#feat_tailcall">tail calls</a></td>` :raw-html:`<td class="yes"></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="yes"></td> <!-- Hexagon -->` :raw-html:`<td class="no"></td> <!-- MBlaze -->` :raw-html:`<td class="unknown"></td> <!-- MSP430 -->` @@ -1883,7 +1881,6 @@ Here is the table: :raw-html:`<tr>` :raw-html:`<td><a href="#feat_segstacks">segmented stacks</a></td>` :raw-html:`<td class="no"></td> <!-- ARM -->` -:raw-html:`<td class="no"></td> <!-- CellSPU -->` :raw-html:`<td class="no"></td> <!-- Hexagon -->` :raw-html:`<td class="no"></td> <!-- MBlaze -->` :raw-html:`<td class="no"></td> <!-- MSP430 -->` @@ -1992,8 +1989,8 @@ Tail call optimization Tail call optimization, callee reusing the stack of the caller, is currently supported on x86/x86-64 and PowerPC. It is performed if: -* Caller and callee have the calling convention ``fastcc`` or ``cc 10`` (GHC - call convention). +* Caller and callee have the calling convention ``fastcc``, ``cc 10`` (GHC + calling convention) or ``cc 11`` (HiPE calling convention). * The call is a tail call - in tail position (ret immediately follows call and ret uses value of call or is void). diff --git a/docs/CodingStandards.rst b/docs/CodingStandards.rst index 90835307b1..8003c12497 100644 --- a/docs/CodingStandards.rst +++ b/docs/CodingStandards.rst @@ -284,17 +284,10 @@ listed. We prefer these ``#include``\s to be listed in this order: #. Main Module Header #. Local/Private Headers -#. ``llvm/*`` -#. ``llvm/Analysis/*`` -#. ``llvm/Assembly/*`` -#. ``llvm/Bitcode/*`` -#. ``llvm/CodeGen/*`` -#. ... -#. ``llvm/Support/*`` -#. ``llvm/Config/*`` +#. ``llvm/...`` #. System ``#include``\s -and each category should be sorted by name. +and each category should be sorted lexicographically by the full path. The `Main Module Header`_ file applies to ``.cpp`` files which implement an interface defined by a ``.h`` file. This ``#include`` should always be included @@ -409,7 +402,8 @@ code. That said, LLVM does make extensive use of a hand-rolled form of RTTI that use templates like `isa<>, cast<>, and dyn_cast<> <ProgrammersManual.html#isa>`_. -This form of RTTI is opt-in and can be added to any class. It is also +This form of RTTI is opt-in and can be +:doc:`added to any class <HowToSetUpLLVMStyleRTTI>`. It is also substantially more efficient than ``dynamic_cast<>``. .. _static constructor: @@ -713,8 +707,8 @@ sort of thing is: .. code-block:: c++ bool FoundFoo = false; - for (unsigned i = 0, e = BarList.size(); i != e; ++i) - if (BarList[i]->isFoo()) { + for (unsigned I = 0, E = BarList.size(); I != E; ++I) + if (BarList[I]->isFoo()) { FoundFoo = true; break; } @@ -732,8 +726,8 @@ code to be structured like this: /// \returns true if the specified list has an element that is a foo. static bool containsFoo(const std::vector<Bar*> &List) { - for (unsigned i = 0, e = List.size(); i != e; ++i) - if (List[i]->isFoo()) + for (unsigned I = 0, E = List.size(); I != E; ++I) |