diff options
Diffstat (limited to 'llvm/docs/MIRLangRef.rst')
| -rw-r--r-- | llvm/docs/MIRLangRef.rst | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/llvm/docs/MIRLangRef.rst b/llvm/docs/MIRLangRef.rst index a505c1e..3f4c3cd 100644 --- a/llvm/docs/MIRLangRef.rst +++ b/llvm/docs/MIRLangRef.rst @@ -27,7 +27,7 @@ data serialization language, and the full YAML language spec can be read at `yaml.org <http://www.yaml.org/spec/1.2/spec.html#Introduction>`_. -A MIR file is split up into a series of `YAML documents`_. The first document +A MIR file is split into a series of `YAML documents`_. The first document can contain an optional embedded LLVM IR module, and the rest of the documents contain the serialized machine functions. @@ -65,22 +65,22 @@ after the name with a comma. ``llc -stop-after=dead-mi-elimination,1 bug-trigger.ll -o test.mir`` -After generating the input MIR file, you'll have to add a run line that uses +After generating the input MIR file, you'll have to add a ``RUN`` line that uses the ``-run-pass`` option to it. In order to test the post register allocation pseudo instruction expansion pass on X86-64, a run line like the one shown below can be used: ``# RUN: llc -o - %s -mtriple=x86_64-- -run-pass=postrapseudos | FileCheck %s`` -The MIR files are target dependent, so they have to be placed in the target -specific test directories (``lib/CodeGen/TARGETNAME``). They also need to -specify a target triple or a target architecture either in the run line or in +The MIR files are target dependent, so they have to be placed in the +target-specific test directories (``lib/CodeGen/TARGETNAME``). They also need to +specify a target triple or a target architecture either in the ``RUN`` line or in the embedded LLVM IR module. Simplifying MIR files ^^^^^^^^^^^^^^^^^^^^^ -The MIR code coming out of ``-stop-after``/``-stop-before`` is very verbose; +The MIR code coming out of ``-stop-after``/``-stop-before`` is very verbose. Tests are more accessible and future proof when simplified: - Use the ``-simplify-mir`` option with llc. @@ -113,12 +113,12 @@ Tests are more accessible and future proof when simplified: If the test doesn't depend on (good) alias analysis the references can be dropped: `:: (load 8)` -- MIR blocks can reference IR blocks for debug printing, profile information +- MIR blocks can reference IR blocks for debug printing, profile information, or debug locations. Example: `bb.42.myblock` in MIR references the IR block `myblock`. It is usually possible to drop the `.myblock` reference and simply use `bb.42`. -- If there are no memory operands or blocks referencing the IR then the +- If there are no memory operands or blocks referencing the IR, then the IR function can be replaced by a parameterless dummy function like `define @func() { ret void }`. @@ -143,7 +143,7 @@ can serialize: - The ``MCSymbol`` machine operands don't support temporary or local symbols. - A lot of the state in ``MachineModuleInfo`` isn't serialized - only the CFI - instructions and the variable debug information from MMI is serialized right + instructions and the variable debug information from MMI are serialized right now. These limitations impose restrictions on what you can test with the MIR format. @@ -182,7 +182,7 @@ Machine Functions ----------------- The remaining YAML documents contain the machine functions. This is an example -of such YAML document: +of such a YAML document: .. code-block:: text @@ -299,7 +299,7 @@ instructions: bb.2.else: <instructions> -The branch weights can be specified in brackets after the successor blocks. +The branch weights can be specified in parentheses after the successor blocks. The example below defines a block that has two successors with branch weights of 32 and 16: @@ -314,7 +314,7 @@ Live In Registers ^^^^^^^^^^^^^^^^^ The machine basic block's live in registers have to be specified before any of -the instructions: +its instructions: .. code-block:: text @@ -322,14 +322,14 @@ the instructions: liveins: $edi, $esi The list of live in registers and successors can be empty. The language also -allows multiple live in register and successor lists - they are combined into +allows multiple live in register and successor lists; they are combined into one list by the parser. Miscellaneous Attributes ^^^^^^^^^^^^^^^^^^^^^^^^ The attributes ``IsAddressTaken``, ``IsLandingPad``, -``IsInlineAsmBrIndirectTarget`` and ``Alignment`` can be specified in brackets +``IsInlineAsmBrIndirectTarget`` and ``Alignment`` can be specified in parentheses after the block's definition: .. code-block:: text @@ -417,7 +417,7 @@ and ``}`` are bundled with the first instruction. Registers --------- -Registers are one of the key primitives in the machine instructions +Registers are one of the key primitives in the machine instruction serialization language. They are primarily used in the :ref:`register machine operands <register-operands>`, but they can also be used in a number of other places, like the @@ -503,9 +503,9 @@ will be printed as ``%subreg.sub_32``: %1:gpr64 = SUBREG_TO_REG 0, %0, %subreg.sub_32 -For integers > 64bit, we use a special machine operand, ``MO_CImmediate``, +For integers > 64 bits, we use a special machine operand, ``MO_CImmediate``, which stores the immediate in a ``ConstantInt`` using an ``APInt`` (LLVM's -arbitrary precision integers). +arbitrary-precision integers). .. TODO: Describe the FPIMM immediate operands. @@ -626,7 +626,7 @@ For a CPI with the index 0 and offset -12: %1:gr64 = MOV64ri %const.0 - 12 A constant pool entry is bound to a LLVM IR ``Constant`` or a target-specific -``MachineConstantPoolValue``. When serializing all the function's constants the +``MachineConstantPoolValue``. When serializing all the function's constants, the following format is used: .. code-block:: text @@ -695,7 +695,7 @@ and the offset 8: Jump-table Index Operands ^^^^^^^^^^^^^^^^^^^^^^^^^ -A jump-table index operand with the index 0 is printed as following: +A jump-table index operand with the index 0 is printed as follows: .. code-block:: text @@ -711,7 +711,7 @@ A machine jump-table entry contains a list of ``MachineBasicBlocks``. When seria - id: <index> blocks: [ <bbreference>, <bbreference>, ... ] -where ``<kind>`` is describing how the jump table is represented and emitted (plain address, relocations, PIC, etc.), and each ``<index>`` is a 32-bit unsigned integer and ``blocks`` contains a list of :ref:`machine basic block references <block-references>`. +where ``<kind>`` describes how the jump table is represented and emitted (plain address, relocations, PIC, etc.), and each ``<index>`` is a 32-bit unsigned integer and ``blocks`` contains a list of :ref:`machine basic block references <block-references>`. Example: @@ -741,7 +741,7 @@ Example: MCSymbol Operands ^^^^^^^^^^^^^^^^^ -A MCSymbol operand is holding a pointer to a ``MCSymbol``. For the limitations +A MCSymbol operand holds a pointer to a ``MCSymbol``. For the limitations of this operand in MIR, see :ref:`limitations <limitations>`. The syntax is: @@ -754,7 +754,7 @@ Debug Instruction Reference Operands ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A debug instruction reference operand is a pair of indices, referring to an -instruction and an operand within that instruction respectively; see +instruction and an operand within that instruction, respectively; see :ref:`Instruction referencing locations <instruction-referencing-locations>`. The example below uses a reference to Instruction 1, Operand 0: @@ -766,7 +766,7 @@ The example below uses a reference to Instruction 1, Operand 0: CFIIndex Operands ^^^^^^^^^^^^^^^^^ -A CFI Index operand is holding an index into a per-function side-table, +A CFI Index operand holds an index into a per-function side-table, ``MachineFunction::getFrameInstructions()``, which references all the frame instructions in a ``MachineFunction``. A ``CFI_INSTRUCTION`` may look like it contains multiple operands, but the only operand it contains is the CFI Index. @@ -842,7 +842,7 @@ Comments can be added or customized by overriding InstrInfo's hook Debug-Info constructs --------------------- -Most of the debugging information in a MIR file is to be found in the metadata +Most of the debugging information in a MIR file is found in the metadata of the embedded module. Within a machine function, that metadata is referred to by various constructs to describe source locations and variable locations. |