[llvm] bb14b83 - [llvm] Proofread MIRLangRef.rst (#166131)
via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 3 08:41:44 PST 2025
Author: Kazu Hirata
Date: 2025-11-03T08:41:41-08:00
New Revision: bb14b831d20a5b22da017d94b046fa40316f8364
URL: https://github.com/llvm/llvm-project/commit/bb14b831d20a5b22da017d94b046fa40316f8364
DIFF: https://github.com/llvm/llvm-project/commit/bb14b831d20a5b22da017d94b046fa40316f8364.diff
LOG: [llvm] Proofread MIRLangRef.rst (#166131)
Added:
Modified:
llvm/docs/MIRLangRef.rst
Removed:
################################################################################
diff --git a/llvm/docs/MIRLangRef.rst b/llvm/docs/MIRLangRef.rst
index 3f4c3cde9b3aa..f7647c898c1e6 100644
--- a/llvm/docs/MIRLangRef.rst
+++ b/llvm/docs/MIRLangRef.rst
@@ -86,25 +86,25 @@ Tests are more accessible and future proof when simplified:
- Use the ``-simplify-mir`` option with llc.
- Machine function attributes often have default values or the test works just
- as well with default values. Typical candidates for this are: `alignment:`,
- `exposesReturnsTwice`, `legalized`, `regBankSelected`, `selected`.
+ as well with default values. Typical candidates for this are: ``alignment:``,
+ ``exposesReturnsTwice``, ``legalized``, ``regBankSelected``, ``selected``.
The whole `frameInfo` section is often unnecessary if there is no special
- frame usage in the function. `tracksRegLiveness` on the other hand is often
+ frame usage in the function. ``tracksRegLiveness`` on the other hand is often
necessary for some passes that care about block livein lists.
-- The (global) `liveins:` list is typically only interesting for early
+- The (global) ``liveins:`` list is typically only interesting for early
instruction selection passes and can be removed when testing later passes.
- The per-block `liveins:` on the other hand are necessary if
+ The per-block ``liveins:`` on the other hand are necessary if
`tracksRegLiveness` is true.
-- Branch probability data in block `successors:` lists can be dropped if the
+- Branch probability data in block ``successors:`` lists can be dropped if the
test doesn't depend on it. Example:
- `successors: %bb.1(0x40000000), %bb.2(0x40000000)` can be replaced with
- `successors: %bb.1, %bb.2`.
+ ``successors: %bb.1(0x40000000), %bb.2(0x40000000)`` can be replaced with
+ ``successors: %bb.1, %bb.2``.
- MIR code contains a whole IR module. This is necessary because there are
no equivalents in MIR for global variables, references to external functions,
- function attributes, metadata, debug info. Instead some MIR data references
+ function attributes, metadata, debug info. Instead, some MIR data references
the IR constructs. You can often remove them if the test doesn't depend on
them.
@@ -114,16 +114,16 @@ Tests are more accessible and future proof when simplified:
dropped: `:: (load 8)`
- 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`.
+ 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
IR function can be replaced by a parameterless dummy function like
- `define @func() { ret void }`.
+ ``define @func() { ret void }``.
- It is possible to drop the whole IR section of the MIR file if it only
- contains dummy functions (see above). The .mir loader will create the
+ contains dummy functions (see above). The ``.mir`` loader will create the
IR functions automatically in this case.
.. _limitations:
@@ -131,7 +131,7 @@ Tests are more accessible and future proof when simplified:
Limitations
-----------
-Currently the MIR format has several limitations in terms of which state it
+Currently, the MIR format has several limitations in terms of which state it
can serialize:
- The target-specific state in the target-specific ``MachineFunctionInfo``
@@ -150,7 +150,7 @@ These limitations impose restrictions on what you can test with the MIR format.
For now, tests that would like to test some behaviour that depends on the state
of temporary or local ``MCSymbol`` operands or the exception handling state in
MMI, can't use the MIR format. As well as that, tests that test some behaviour
-that depends on the state of the target specific ``MachineFunctionInfo`` or
+that depends on the state of the target-specific ``MachineFunctionInfo`` or
``MachineConstantPoolValue`` subclasses can't use the MIR format at the moment.
High Level Structure
@@ -286,7 +286,7 @@ Example:
Successors
^^^^^^^^^^
-The machine basic block's successors have to be specified before any of the
+The machine basic block's successors must be specified before any of the
instructions:
.. code-block:: text
@@ -489,13 +489,13 @@ In case this is true, the Machine Operand is printed according to the target.
For example:
-In AArch64RegisterInfo.td:
+In ``AArch64RegisterInfo.td``:
.. code-block:: text
def sub_32 : SubRegIndex<32>;
-If the third operand is an immediate with the value ``15`` (target-dependent
+If the third operand is an immediate with the value ``15`` (a target-dependent
value), based on the instruction's opcode and the operand's index the operand
will be printed as ``%subreg.sub_32``:
@@ -503,7 +503,7 @@ will be printed as ``%subreg.sub_32``:
%1:gpr64 = SUBREG_TO_REG 0, %0, %subreg.sub_32
-For integers > 64 bits, we use a special machine operand, ``MO_CImmediate``,
+For integers larger than 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).
@@ -552,7 +552,7 @@ corresponding internal ``llvm::RegState`` representation:
* - ``implicit``
- ``RegState::Implicit``
- - Not emitted register (e.g. carry, or temporary result).
+ - Not emitted register (e.g., carry, or temporary result).
* - ``implicit-def``
- ``RegState::ImplicitDefine``
@@ -625,7 +625,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
+A constant pool entry is bound to an LLVM IR ``Constant`` or a target-specific
``MachineConstantPoolValue``. When serializing all the function's constants, the
following format is used:
@@ -670,12 +670,12 @@ a global value operand named ``G``:
$rax = MOV64rm $rip, 1, _, @G, _
-The named global values are represented using an identifier with the '@' prefix.
+The named global values are represented using an identifier with the ``@`` prefix.
If the identifier doesn't match the regular expression
-`[-a-zA-Z$._][-a-zA-Z$._0-9]*`, then this identifier must be quoted.
+``[-a-zA-Z$._][-a-zA-Z$._0-9]*``, then this identifier must be quoted.
The unnamed global values are represented using an unsigned numeric value with
-the '@' prefix, like in the following examples: ``@0``, ``@989``.
+the ``@`` prefix, as in the following examples: ``@0``, ``@989``.
Target-dependent Index Operands
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -741,7 +741,7 @@ Example:
MCSymbol Operands
^^^^^^^^^^^^^^^^^
-A MCSymbol operand holds a pointer to a ``MCSymbol``. For the limitations
+An ``MCSymbol`` operand holds a pointer to an ``MCSymbol``. For the limitations
of this operand in MIR, see :ref:`limitations <limitations>`.
The syntax is:
@@ -825,7 +825,7 @@ Comments
^^^^^^^^
Machine operands can have C/C++ style comments, which are annotations enclosed
-between ``/*`` and ``*/`` to improve readability of e.g. immediate operands.
+between ``/*`` and ``*/`` to improve readability of e.g., immediate operands.
In the example below, ARM instructions EOR and BCC and immediate operands
``14`` and ``0`` have been annotated with their condition codes (CC)
definitions, i.e. the ``always`` and ``eq`` condition codes:
@@ -920,7 +920,7 @@ Instruction referencing locations
This experimental feature aims to separate the specification of variable
*values* from the program point where a variable takes on that value. Changes
-in variable value occur in the same manner as ``DBG_VALUE`` meta instructions
+in a variable value occur in the same manner as ``DBG_VALUE`` meta instructions
but using ``DBG_INSTR_REF``. Variable values are identified by a pair of
instruction number and operand number. Consider the example below:
More information about the llvm-commits
mailing list