[llvm] Proofread MIRLangRef.rst (llvm#152263)

Author: kazutakahirata

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,22 +314,22 @@ 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
 
     bb.0.entry:
       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.