[docs] Enable syntax highlight of MIR (requires pygments 2.6.1)

[dsanders]

Summary

pygments 2.6.1 contains support for MIR syntax highlighting.
It's been a couple months since that was released so I'd like
to suggest enabling it in our docs. There are two lexers
available, llvm-mir is for full MIR examples, and
llvm-mir-body is for examples of the body section without the
usual YAML wrapper.

It looks like I missed a few things in the pygments lexer as
some of these MIR examples don't highlight. Some like 'BUNDLE'
I intentionally didn't cover in the first attempt but it seems
I missed some keywords too (e.g. implicit-def, frame-setup,
frame-destroy), some LLVM-IR variable characters, and <regmask...>
Unfortunately, sphinx doesn't warn when pygments emits an
Error token (it silently drops all highlighting) so there may be more.

A few subsections in MIR are also not highlighted but they
don't cause unrelated highlights to disappear. E.g. the constants
section.

llvm/docs/GlobalISel/GenericOpcode.rst

 Constants
 ---------
 
 G_IMPLICIT_DEF
 ^^^^^^^^^^^^^^
 
 An undefined value.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %0:_(s32) = G_IMPLICIT_DEF
 
 G_CONSTANT
 ^^^^^^^^^^
 
 An integer constant.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %0:_(s32) = G_CONSTANT i32 1
 
 G_FCONSTANT
 ^^^^^^^^^^^
 
 A floating point constant.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %0:_(s32) = G_FCONSTANT float 1.0
 
 G_FRAME_INDEX
 ^^^^^^^^^^^^^
 
 The address of an object in the stack frame.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(p0) = G_FRAME_INDEX %stack.0.ptr0
 
 G_GLOBAL_VALUE
 ^^^^^^^^^^^^^^
 
 The address of a global value.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %0(p0) = G_GLOBAL_VALUE @var_local
 
 G_BLOCK_ADDR
 ^^^^^^^^^^^^
 
 The address of a basic block.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %0:_(p0) = G_BLOCK_ADDR blockaddress(@test_blockaddress, %ir-block.block)
 
 Integer Extension and Truncation
 --------------------------------
 
 G_ANYEXT
 ^^^^^^^^
 
 Extend the underlying scalar type of an operation, leaving the high bits
 unspecified.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s32) = G_ANYEXT %0:_(s16)
 
 G_SEXT
 ^^^^^^
 
 Sign extend the underlying scalar type of an operation, copying the sign bit
 into the newly-created space.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s32) = G_SEXT %0:_(s16)
 
 G_SEXT_INREG
 ^^^^^^^^^^^^
 
 Sign extend the value from an arbitrary bit position, copying the sign bit
 into all bits above it. This is equivalent to a shl + ashr pair with an
 appropriate shift amount. $sz is an immediate (MachineOperand::isImm()
 returns true) to allow targets to have some bitwidths legal and others
 lowered. This opcode is particularly useful if the target has sign-extension
 instructions that are cheaper than the constituent shifts as the optimizer is
 able to make decisions on whether it's better to hang on to the G_SEXT_INREG
 or to lower it and optimize the individual shifts.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s32) = G_SEXT_INREG %0:_(s32), 16
 
 G_ZEXT
 ^^^^^^
 
 Zero extend the underlying scalar type of an operation, putting zero bits
 into the newly-created space.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s32) = G_ZEXT %0:_(s16)
 
 G_TRUNC
 ^^^^^^^
 
 Truncate the underlying scalar type of an operation. This is equivalent to
 G_EXTRACT for scalar types, but acts elementwise on vectors.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s16) = G_TRUNC %0:_(s32)
 
 Type Conversions
 ----------------
 
 G_INTTOPTR
 ^^^^^^^^^^
 
 Convert an integer to a pointer.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(p0) = G_INTTOPTR %0:_(s32)
 
 G_PTRTOINT
 ^^^^^^^^^^
 
 Convert a pointer to an integer.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s32) = G_PTRTOINT %0:_(p0)
 
 G_BITCAST
 ^^^^^^^^^
 
 Reinterpret a value as a new type. This is usually done without changing any
 bits but this is not always the case due a sublety in the definition of the
 :ref:`LLVM-IR Bitcast Instruction <i_bitcast>`.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s64) = G_BITCAST %0:_(<2 x s32>)
 
 G_ADDRSPACE_CAST
 ^^^^^^^^^^^^^^^^
 
 Convert a pointer to an address space to a pointer to another address space.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(p1) = G_ADDRSPACE_CAST %0:_(p0)
 
 .. caution::
 
   :ref:`i_addrspacecast` doesn't mention what happens if the cast is simply
   invalid (i.e. if the address spaces are disjoint).
 

 Insert a smaller register into a larger one at the specified bit-index.
 
 G_MERGE_VALUES
 ^^^^^^^^^^^^^^
 
 Concatenate multiple registers of the same size into a wider register.
 The input operands are always ordered from lowest bits to highest:
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %0:(s32) = G_MERGE_VALUES %bits_0_7:(s8), %bits_8_15:(s8),
                             %bits_16_23:(s8), %bits_24_31:(s8)
 
 G_UNMERGE_VALUES
 ^^^^^^^^^^^^^^^^
 
 Extract multiple registers of the specified size, starting from blocks given by
 indexes. This will almost certainly be mapped to sub-register COPYs after
 register banks have been selected.
 The output operands are always ordered from lowest bits to highest:
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %bits_0_7:(s8), %bits_8_15:(s8),
       %bits_16_23:(s8), %bits_24_31:(s8) = G_UNMERGE_VALUES %0:(s32)
 
 G_BSWAP
 ^^^^^^^
 
 Reverse the order of the bytes in a scalar.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s32) = G_BSWAP %0:_(s32)
 
 G_BITREVERSE
 ^^^^^^^^^^^^
 
 Reverse the order of the bits in a scalar.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(s32) = G_BITREVERSE %0:_(s32)
 
 Integer Operations
 -------------------
 
 G_ADD, G_SUB, G_MUL, G_AND, G_OR, G_XOR, G_SDIV, G_UDIV, G_SREM, G_UREM
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 These each perform their respective integer arithmetic on a scalar.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %2:_(s32) = G_ADD %0:_(s32), %1:_(s32)
 
 G_SADDSAT, G_UADDSAT, G_SSUBSAT, G_USUBSAT
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Signed and unsigned addition and subtraction with saturation.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %2:_(s32) = G_SADDSAT %0:_(s32), %1:_(s32)
 
 G_SHL, G_LSHR, G_ASHR
 ^^^^^^^^^^^^^^^^^^^^^
 
 Shift the bits of a scalar left or right inserting zeros (sign-bit for G_ASHR).
 
 G_ICMP
 ^^^^^^
 
 Perform integer comparison producing non-zero (true) or zero (false). It's
 target specific whether a true value is 1, ~0U, or some other non-zero value.
 
 G_SELECT
 ^^^^^^^^
 
 Select between two values depending on a zero/non-zero value.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %5:_(s32) = G_SELECT %4(s1), %6, %2
 
 G_PTR_ADD
 ^^^^^^^^^
 
 Add a scalar offset in addressible units to a pointer. Addressible units are
 typically bytes but this may vary between targets.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(p0) = G_PTR_ADD %0:_(p0), %1:_(s32)
 
 .. caution::
 
   There are currently no in-tree targets that use this with addressable units
   not equal to 8 bit.
 
 G_PTR_MASK
 ^^^^^^^^^^
 
 Zero the least significant N bits of a pointer.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:_(p0) = G_PTR_MASK %0, 3
 
 G_SMIN, G_SMAX, G_UMIN, G_UMAX
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Take the minimum/maximum of two values.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %5:_(s32) = G_SMIN %6, %2
 
 G_UADDO, G_SADDO, G_USUBO, G_SSUBO, G_SMULO, G_UMULO
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Perform the requested arithmetic and produce a carry output in addition to the
 normal result.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %3:_(s32), %4:_(s1) = G_UADDO %0, %1
 
 G_UADDE, G_SADDE, G_USUBE, G_SSUBE
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Perform the requested arithmetic and consume a carry input in addition to the
 normal input. Also produce a carry output in addition to the normal result.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %4:_(s32), %5:_(s1) = G_UADDE %0, %1, %3:_(s1)
 
 G_UMULH, G_SMULH
 ^^^^^^^^^^^^^^^^
 
 Multiply two numbers at twice the incoming bit width (signed) and return
 the high half of the result.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %3:_(s32) = G_UMULH %0, %1
 
 G_CTLZ, G_CTTZ, G_CTPOP
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 Count leading zeros, trailing zeros, or number of set bits.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %2:_(s33) = G_CTLZ_ZERO_UNDEF %1
   %2:_(s33) = G_CTTZ_ZERO_UNDEF %1
   %2:_(s33) = G_CTPOP %1
 
 G_CTLZ_ZERO_UNDEF, G_CTTZ_ZERO_UNDEF
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Count leading zeros or trailing zeros. If the value is zero then the result is
 undefined.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %2:_(s33) = G_CTLZ_ZERO_UNDEF %1
   %2:_(s33) = G_CTTZ_ZERO_UNDEF %1
 
 Floating Point Operations
 -------------------------
 
 G_FCMP

 Control Flow
 ------------
 
 G_PHI
 ^^^^^
 
 Implement the φ node in the SSA graph representing the function.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1(s8) = G_PHI %7(s8), %bb.0, %3(s8), %bb.1
 
 G_BR
 ^^^^
 
 Unconditional branch
 

 ----------------
 
 G_DYN_STACKALLOC
 ^^^^^^^^^^^^^^^^
 
 Dynamically realigns the stack pointer to the specified size and alignment.
 An alignment value of `0` or `1` mean no specific alignment.
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %8:_(p0) = G_DYN_STACKALLOC %7(s64), 32

llvm/docs/GlobalISel/IRTranslator.rst

 occasionally get a bit more involved. For example:
 
 .. code-block:: llvm
 
   %2 = add i32 %0, %1
 
 becomes:
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %2:_(s32) = G_ADD %0:_(s32), %1:_(s32)
 
 whereas
 
 .. code-block:: llvm
 
   call i32 @puts(i8* %cast210)

llvm/docs/GlobalISel/KnownBits.rst

into::
 
   a | 1
 
 is only valid when the addition doesn't carry. In other words it's only valid
 if ``a & 1`` is zero.
 
 Another example is:
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
   %1:(s32) = G_CONSTANT i32 0xFF0
   %2:(s32) = G_AND %0, %1
   %3:(s32) = G_CONSTANT i32 0x0FF
   %4:(s32) = G_AND %2, %3
 
 We can use the constants and the definition of ``G_AND`` to determine the known
 bits:
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
                                    ; %0 = 0x????????
   %1:(s32) = G_CONSTANT i32 0xFF0  ; %1 = 0x00000FF0
   %2:(s32) = G_AND %0, %1          ; %2 = 0x00000??0
   %3:(s32) = G_CONSTANT i32 0x0FF  ; %3 = 0x000000FF
   %4:(s32) = G_AND %2, %3          ; %4 = 0x000000?0
 
 and then use this to simplify the expression:
 
-.. code-block:: none
+.. code-block:: llvm-mir-body
 
                                    ; %0 = 0x????????
   %5:(s32) = G_CONSTANT i32 0x0F0  ; %5 = 0x00000FF0
   %4:(s32) = G_AND %0, %5          ; %4 = 0x000000?0
 
 Note that ``%4`` still has the same known bits as before the transformation.
 Many transformations share this property. The main exception being when the
 transform causes undefined bits to become defined to either zero, one, or

llvm/docs/MIRLangRef.rst

 .. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688
 
 Machine Functions
 -----------------
 
 The remaining YAML documents contain the machine functions. This is an example
 of such YAML document:
 
-.. code-block:: text
+.. code-block:: llvm-mir
 
      ---
      name:            inc
      tracksRegLiveness: true
      liveins:
        - { reg: '$rdi' }
      callSites:
        - { bb: 0, offset: 3, fwdArgRegs:

 blocks are referenced using the following syntax:
 
 .. code-block:: text
 
     %bb.<id>
 
 Example:
 
-.. code-block:: llvm
+.. code-block:: llvm-mir-body
 
     %bb.0
 
 The following syntax is also supported, but the former syntax is preferred for
 block references:
 
 .. code-block:: text
 
     %bb.<id>[.<name>]
 
 Example:
 
-.. code-block:: llvm
+.. code-block:: llvm-mir-body
 
     %bb.1.then
 
 Successors
 ^^^^^^^^^^
 
 The machine basic block's successors have to be specified before any of the
 instructions:
 
 .. code-block:: text
 
     bb.0.entry:
       successors: %bb.1.then, %bb.2.else
       <instructions>
     bb.1.then:
       <instructions>
     bb.2.else:
       <instructions>
 
 The branch weights can be specified in brackets after the successor blocks.
 The example below defines a block that has two successors with branch weights
 of 32 and 16:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     bb.0.entry:
       successors: %bb.1.then(32), %bb.2.else(16)
 
 .. _bb-liveins:
 
 Live In Registers
 ^^^^^^^^^^^^^^^^^
 
 The machine basic block's live in registers have to be specified before any of
 the instructions:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     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
 one list by the parser.
 

 A machine instruction is composed of a name,
 :ref:`machine operands <machine-operands>`,
 :ref:`instruction flags <instruction-flags>`, and machine memory operands.
 
 The instruction's name is usually specified before the operands. The example
 below shows an instance of the X86 ``RETQ`` instruction with a single machine
 operand:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     RETQ $eax
 
 However, if the machine instruction has one or more explicitly defined register
 operands, the instruction's name has to be specified after them. The example
 below shows an instance of the AArch64 ``LDPXpost`` instruction with three
 defined register operands:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     $sp, $fp, $lr = LDPXpost $sp, 2
 
 The instruction names are serialized using the exact definitions from the
 target's ``*InstrInfo.td`` files, and they are case sensitive. This means that
 similar instruction names like ``TSTri`` and ``tSTRi`` represent different
 machine instructions.
 
 .. _instruction-flags:
 
 Instruction Flags
 ^^^^^^^^^^^^^^^^^
 
 The flag ``frame-setup`` or ``frame-destroy`` can be specified before the
 instruction's name:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     $fp = frame-setup ADDXri $sp, 0, 0
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     $x21, $x20 = frame-destroy LDPXi $sp
 
 .. _registers:
 
 Bundled Instructions
 ^^^^^^^^^^^^^^^^^^^^
 
 The syntax for bundled instructions is the following:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     BUNDLE implicit-def $r0, implicit-def $r1, implicit $r2 {
       $r0 = SOME_OP $r2
       $r1 = ANOTHER_OP internal $r0
     }
 
 The first instruction is often a bundle header. The instructions between ``{``
 and ``}`` are bundled with the first instruction.

 They use the following syntax:
 
 .. code-block:: text
 
     $<name>
 
 The example below shows three X86 physical registers:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     $eax
     $r15
     $eflags
 
 The virtual registers are identified by their ID number and by the '%' sigil.
 They use the following syntax:
 
 .. code-block:: text
 
     %<id>
 
 Example:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     %0
 
 The null registers are represented using an underscore ('``_``'). They can also be
 represented using a '``$noreg``' named register, although the former syntax
 is preferred.
 
 .. _machine-operands:
 
 Machine Operands
 ----------------
 
 There are seventeen different kinds of machine operands, and all of them can be
 serialized.
 
 Immediate Operands
 ^^^^^^^^^^^^^^^^^^
 
 The immediate machine operands are untyped, 64-bit signed integers. The
 example below shows an instance of the X86 ``MOV32ri`` instruction that has an
 immediate machine operand ``-42``:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     $eax = MOV32ri -42
 
 An immediate operand is also used to represent a subregister index when the
 machine instruction has one of the following opcodes:
 
 - ``EXTRACT_SUBREG``
 

 .. code-block:: text
 
   def sub_32 : SubRegIndex<32>;
 
 If the third operand is an immediate with the value ``15`` (target-dependent
 value), based on the instruction's opcode and the operand's index the operand
 will be printed as ``%subreg.sub_32``:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     %1:gpr64 = SUBREG_TO_REG 0, %0, %subreg.sub_32
 
 For integers > 64bit, we use a special machine operand, ``MO_CImmediate``,
 which stores the immediate in a ``ConstantInt`` using an ``APInt`` (LLVM's
 arbitrary precision integers).
 
 .. TODO: Describe the FPIMM immediate operands.
 
 .. _register-operands:
 
 Register Operands
 ^^^^^^^^^^^^^^^^^
 
 The :ref:`register <registers>` primitive is used to represent the register
 machine operands. The register operands can also have optional
 :ref:`register flags <register-flags>`,
 :ref:`a subregister index <subregister-indices>`,
 and a reference to the tied register operand.
 The full syntax of a register operand is shown below:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     [<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def <tied-op>) ]
 
 This example shows an instance of the X86 ``XOR32rr`` instruction that has
 5 register operands with different register flags:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
   dead $eax = XOR32rr undef $eax, undef $eax, implicit-def dead $eflags, implicit-def $al
 
 .. _register-flags:
 
 Register Flags
 ~~~~~~~~~~~~~~
 

 Subregister Indices
 ~~~~~~~~~~~~~~~~~~~
 
 The register machine operands can reference a portion of a register by using
 the subregister indices. The example below shows an instance of the ``COPY``
 pseudo instruction that uses the X86 ``sub_8bit`` subregister index to copy 8
 lower bits from the 32-bit virtual register 0 to the 8-bit virtual register 1:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     %1 = COPY %0:sub_8bit
 
 The names of the subregister indices are target specific, and are typically
 defined in the target's ``*RegisterInfo.td`` file.
 
 Constant Pool Indices
 ^^^^^^^^^^^^^^^^^^^^^
 
 A constant pool index (CPI) operand is printed using its index in the
 function's ``MachineConstantPool`` and an offset.
 
 For example, a CPI with the index 1 and offset 8:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     %1:gr64 = MOV64ri %const.1 + 8
 
 For a CPI with the index 0 and offset -12:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     %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
 following format is used:
 
 .. code-block:: text
where:
   - ``<value>`` is a `LLVM IR Constant
     <https://www.llvm.org/docs/LangRef.html#constants>`_;
   - ``<alignment>`` is a 32-bit unsigned integer specified in bytes, and must be
     power of two;
   - ``<target-specific>`` is either true or false.
 
 Example:
 
-.. code-block:: text
+.. code-block:: llvm-mir
 
     constants:
       - id:               0
         value:            'double 3.250000e+00'
         alignment:        8
       - id:               1
         value:            'g-(LPC0+8)'
         alignment:        4
         isTargetSpecific: true
 
 Global Value Operands
 ^^^^^^^^^^^^^^^^^^^^^
 
 The global value machine operands reference the global values from the
 :ref:`embedded LLVM IR module <embedded-module>`.
 The example below shows an instance of the X86 ``MOV64rm`` instruction that has
 a global value operand named ``G``:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     $rax = MOV64rm $rip, 1, _, @G, _
 
 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.
 
 The unnamed global values are represented using an unsigned numeric value with
 the '@' prefix, like in the following examples: ``@0``, ``@989``.
 
 Target-dependent Index Operands
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 A target index operand is a target-specific index and an offset. The
 target-specific index is printed using target-specific names and a positive or
 negative offset.
 
 For example, the ``amdgpu-constdata-start`` is associated with the index ``0``
 in the AMDGPU backend. So if we have a target index operand with the index 0
 and the offset 8:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     $sgpr2 = S_ADD_U32 _, target-index(amdgpu-constdata-start) + 8, implicit-def _, implicit-def _
 
 Jump-table Index Operands
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 A jump-table index operand with the index 0 is printed as following:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
-    tBR_JTr killed $r0, %jump-table.0
+    tBR_JTr $r0, %jump-table.0
 
 A machine jump-table entry contains a list of ``MachineBasicBlocks``. When serializing all the function's jump-table entries, the following format is used:
 
 .. code-block:: text
 
     jumpTable:
       kind:             <kind>
       entries:
         - 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>`.
 
 Example:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     jumpTable:
       kind:             inline
       entries:
         - id:             0
           blocks:         [ '%bb.3', '%bb.9', '%bb.4.d3' ]
         - id:             1
           blocks:         [ '%bb.7', '%bb.7', '%bb.4.d3', '%bb.5' ]
 
 External Symbol Operands
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 An external symbol operand is represented using an identifier with the ``&``
 prefix. The identifier is surrounded with ""'s and escaped if it has any
 special non-printable characters in it.
 
 Example:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     CALL64pcrel32 &__stack_chk_fail, csr_64, implicit $rsp, implicit-def $rsp
 
 MCSymbol Operands
 ^^^^^^^^^^^^^^^^^
 
 A MCSymbol operand is holding a pointer to a ``MCSymbol``. For the limitations
 of this operand in MIR, see :ref:`limitations <limitations>`.

 A CFI Index operand is holding 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.
 The other operands are tracked by the ``MCCFIInstruction`` object.
 
 The syntax is:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     CFI_INSTRUCTION offset $w30, -16
 
 which may be emitted later in the MC layer as:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
     .cfi_offset w30, -16
 
 IntrinsicID Operands
 ^^^^^^^^^^^^^^^^^^^^
 
 An Intrinsic ID operand contains a generic intrinsic ID or a target-specific ID.
 
 The syntax for the ``returnaddress`` intrinsic is:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
    $x0 = COPY intrinsic(@llvm.returnaddress)
 
 Predicate Operands
 ^^^^^^^^^^^^^^^^^^
 
 A Predicate operand contains an IR predicate from ``CmpInst::Predicate``, like
 ``ICMP_EQ``, etc.
 
 For an int eq predicate ``ICMP_EQ``, the syntax is:
 
-.. code-block:: text
+.. code-block:: llvm-mir-body
 
    %2:gpr(s32) = G_ICMP intpred(eq), %0, %1
 
 .. TODO: Describe the parsers default behaviour when optional YAML attributes
    are missing.
 .. TODO: Describe the syntax for virtual register YAML definitions.
 .. TODO: Describe the machine function's YAML flag attributes.
 .. TODO: Describe the syntax for the register mask machine operands.
 .. TODO: Describe the frame information YAML mapping.
 .. TODO: Describe the syntax of the stack object machine operands and their
    YAML definitions.
 .. TODO: Describe the syntax of the block address machine operands.
 .. TODO: Describe the syntax of the metadata machine operands, and the
    instructions debug location attribute.
 .. TODO: Describe the syntax of the register live out machine operands.
 .. TODO: Describe the syntax of the machine memory operands.