[llvm-branch-commits] [llvm] [docs] Migrate 20 LLVM docs to markdown (PR #201465)

Tobias Hieta via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Thu Jun 4 07:48:14 PDT 2026


================
@@ -114,704 +107,596 @@ 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:
+(limitations)=
 
-Limitations
------------
+### Limitations
 
 Currently, the MIR format has several limitations in terms of which state it
 can serialize:
 
-- The target-specific state in the target-specific ``MachineFunctionInfo``
+- The target-specific state in the target-specific `MachineFunctionInfo`
   subclasses isn't serialized at the moment.
 
-- The target-specific ``MachineConstantPoolValue`` subclasses (in the ARM and
+- The target-specific `MachineConstantPoolValue` subclasses (in the ARM and
   SystemZ backends) aren't serialized at the moment.
 
-- The ``MCSymbol`` machine operands don't support temporary or local symbols.
+- The `MCSymbol` machine operands don't support temporary or local symbols.
 
-- A lot of the state in ``MachineModuleInfo`` isn't serialized - only the CFI
+- A lot of the state in `MachineModuleInfo` isn't serialized - only the CFI
   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.
 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
+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
-``MachineConstantPoolValue`` subclasses can't use the MIR format at the moment.
+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
-====================
+## High Level Structure
 
-.. _embedded-module:
+(embedded-module)=
 
-Embedded Module
----------------
+### Embedded Module
 
-When the first YAML document contains a `YAML block literal string`_, the MIR
+When the first YAML document contains a [YAML block literal string], the MIR
 parser will treat this string as an LLVM assembly language string that
 represents an embedded LLVM IR module.
 Here is an example of a YAML document that contains an LLVM module:
 
-.. code-block:: llvm
+```llvm
+   define i32 @inc(ptr %x) {
+   entry:
+     %0 = load i32, ptr %x
+     %1 = add i32 %0, 1
+     store i32 %1, ptr %x
+     ret i32 %1
+   }
+```
+[YAML block literal string]: http://www.yaml.org/spec/1.2/spec.html#id2795688
 
-       define i32 @inc(ptr %x) {
-       entry:
-         %0 = load i32, ptr %x
-         %1 = add i32 %0, 1
-         store i32 %1, ptr %x
-         ret i32 %1
-       }
-
-.. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688
-
-Machine Functions
------------------
+### Machine Functions
 
 The remaining YAML documents contain the machine functions. This is an example
 of such a YAML document:
 
-.. code-block:: text
-
-     ---
-     name:            inc
-     tracksRegLiveness: true
-     liveins:
-       - { reg: '$rdi' }
-     callSites:
-       - { bb: 0, offset: 3, fwdArgRegs:
-           - { arg: 0, reg: '$edi' } }
-     body: |
-       bb.0.entry:
-         liveins: $rdi
-
-         $eax = MOV32rm $rdi, 1, _, 0, _
-         $eax = INC32r killed $eax, implicit-def dead $eflags
-         MOV32mr killed $rdi, 1, _, 0, _, $eax
-         CALL64pcrel32 @foo <regmask...>
-         RETQ $eax
-     ...
-
+```text
+ ---
+ name:            inc
+ tracksRegLiveness: true
+ liveins:
+   - { reg: '$rdi' }
+ callSites:
+   - { bb: 0, offset: 3, fwdArgRegs:
+       - { arg: 0, reg: '$edi' } }
+ body: |
+   bb.0.entry:
+     liveins: $rdi
+
+     $eax = MOV32rm $rdi, 1, _, 0, _
+     $eax = INC32r killed $eax, implicit-def dead $eflags
+     MOV32mr killed $rdi, 1, _, 0, _, $eax
+     CALL64pcrel32 @foo <regmask...>
+     RETQ $eax
+ ...
----------------
tru wrote:

I think this line shouldn't be there right? it's translated from the RST end of block.

https://github.com/llvm/llvm-project/pull/201465


More information about the llvm-branch-commits mailing list