1 ========================================
2 Machine IR (MIR) Format Reference Manual
3 ========================================
9 This is a work in progress.
14 This document is a reference manual for the Machine IR (MIR) serialization
15 format. MIR is a human readable serialization format that is used to represent
16 LLVM's :ref:`machine specific intermediate representation
17 <machine code representation>`.
19 The MIR serialization format is designed to be used for testing the code
20 generation passes in LLVM.
25 The MIR serialization format uses a YAML container. YAML is a standard
26 data serialization language, and the full YAML language spec can be read at
28 <http://www.yaml.org/spec/1.2/spec.html#Introduction>`_.
30 A MIR file is split up into a series of `YAML documents`_. The first document
31 can contain an optional embedded LLVM IR module, and the rest of the documents
32 contain the serialized machine functions.
34 .. _YAML documents: http://www.yaml.org/spec/1.2/spec.html#id2800132
39 You can use the MIR format for testing in two different ways:
41 - You can write MIR tests that invoke a single code generation pass using the
42 ``-run-pass`` option in llc.
44 - You can use llc's ``-stop-after`` option with existing or new LLVM assembly
45 tests and check the MIR output of a specific code generation pass.
47 Testing Individual Code Generation Passes
48 -----------------------------------------
50 The ``-run-pass`` option in llc allows you to create MIR tests that invoke just
51 a single code generation pass. When this option is used, llc will parse an
52 input MIR file, run the specified code generation pass(es), and output the
55 You can generate an input MIR file for the test by using the ``-stop-after`` or
56 ``-stop-before`` option in llc. For example, if you would like to write a test
57 for the post register allocation pseudo instruction expansion pass, you can
58 specify the machine copy propagation pass in the ``-stop-after`` option, as it
59 runs just before the pass that we are trying to test:
61 ``llc -stop-after=machine-cp bug-trigger.ll > test.mir``
63 After generating the input MIR file, you'll have to add a run line that uses
64 the ``-run-pass`` option to it. In order to test the post register allocation
65 pseudo instruction expansion pass on X86-64, a run line like the one shown
68 ``# RUN: llc -o - %s -mtriple=x86_64-- -run-pass=postrapseudos | FileCheck %s``
70 The MIR files are target dependent, so they have to be placed in the target
71 specific test directories (``lib/CodeGen/TARGETNAME``). They also need to
72 specify a target triple or a target architecture either in the run line or in
73 the embedded LLVM IR module.
78 The MIR code coming out of ``-stop-after``/``-stop-before`` is very verbose;
79 Tests are more accessible and future proof when simplified:
81 - Use the ``-simplify-mir`` option with llc.
83 - Machine function attributes often have default values or the test works just
84 as well with default values. Typical candidates for this are: `alignment:`,
85 `exposesReturnsTwice`, `legalized`, `regBankSelected`, `selected`.
86 The whole `frameInfo` section is often unnecessary if there is no special
87 frame usage in the function. `tracksRegLiveness` on the other hand is often
88 necessary for some passes that care about block livein lists.
90 - The (global) `liveins:` list is typically only interesting for early
91 instruction selection passes and can be removed when testing later passes.
92 The per-block `liveins:` on the other hand are necessary if
93 `tracksRegLiveness` is true.
95 - Branch probability data in block `successors:` lists can be dropped if the
96 test doesn't depend on it. Example:
97 `successors: %bb.1(0x40000000), %bb.2(0x40000000)` can be replaced with
98 `successors: %bb.1, %bb.2`.
100 - MIR code contains a whole IR module. This is necessary because there are
101 no equivalents in MIR for global variables, references to external functions,
102 function attributes, metadata, debug info. Instead some MIR data references
103 the IR constructs. You can often remove them if the test doesn't depend on
106 - Alias Analysis is performed on IR values. These are referenced by memory
107 operands in MIR. Example: `:: (load 8 from %ir.foobar, !alias.scope !9)`.
108 If the test doesn't depend on (good) alias analysis the references can be
109 dropped: `:: (load 8)`
111 - MIR blocks can reference IR blocks for debug printing, profile information
112 or debug locations. Example: `bb.42.myblock` in MIR references the IR block
113 `myblock`. It is usually possible to drop the `.myblock` reference and simply
116 - If there are no memory operands or blocks referencing the IR then the
117 IR function can be replaced by a parameterless dummy function like
118 `define @func() { ret void }`.
120 - It is possible to drop the whole IR section of the MIR file if it only
121 contains dummy functions (see above). The .mir loader will create the
122 IR functions automatically in this case.
129 Currently the MIR format has several limitations in terms of which state it
132 - The target-specific state in the target-specific ``MachineFunctionInfo``
133 subclasses isn't serialized at the moment.
135 - The target-specific ``MachineConstantPoolValue`` subclasses (in the ARM and
136 SystemZ backends) aren't serialized at the moment.
138 - The ``MCSymbol`` machine operands are only printed, they can't be parsed.
140 - A lot of the state in ``MachineModuleInfo`` isn't serialized - only the CFI
141 instructions and the variable debug information from MMI is serialized right
144 These limitations impose restrictions on what you can test with the MIR format.
145 For now, tests that would like to test some behaviour that depends on the state
146 of certain ``MCSymbol`` operands or the exception handling state in MMI, can't
147 use the MIR format. As well as that, tests that test some behaviour that
148 depends on the state of the target specific ``MachineFunctionInfo`` or
149 ``MachineConstantPoolValue`` subclasses can't use the MIR format at the moment.
159 When the first YAML document contains a `YAML block literal string`_, the MIR
160 parser will treat this string as an LLVM assembly language string that
161 represents an embedded LLVM IR module.
162 Here is an example of a YAML document that contains an LLVM module:
166 define i32 @inc(i32* %x) {
168 %0 = load i32, i32* %x
170 store i32 %1, i32* %x
174 .. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688
179 The remaining YAML documents contain the machine functions. This is an example
180 of such YAML document:
186 tracksRegLiveness: true
193 %eax = MOV32rm %rdi, 1, _, 0, _
194 %eax = INC32r killed %eax, implicit-def dead %eflags
195 MOV32mr killed %rdi, 1, _, 0, _, %eax
199 The document above consists of attributes that represent the various
200 properties and data structures in a machine function.
202 The attribute ``name`` is required, and its value should be identical to the
203 name of a function that this machine function is based on.
205 The attribute ``body`` is a `YAML block literal string`_. Its value represents
206 the function's machine basic blocks and their machine instructions.
208 Machine Instructions Format Reference
209 =====================================
211 The machine basic blocks and their instructions are represented using a custom,
212 human readable serialization language. This language is used in the
213 `YAML block literal string`_ that corresponds to the machine function's body.
215 A source string that uses this language contains a list of machine basic
216 blocks, which are described in the section below.
221 A machine basic block is defined in a single block definition source construct
222 that contains the block's ID.
223 The example below defines two blocks that have an ID of zero and one:
232 A machine basic block can also have a name. It should be specified after the ID
233 in the block's definition:
237 bb.0.entry: ; This block's name is "entry"
240 The block's name should be identical to the name of the IR block that this
241 machine block is based on.
243 .. _block-references:
248 The machine basic blocks are identified by their ID numbers. Individual
249 blocks are referenced using the following syntax:
261 The following syntax is also supported, but the former syntax is preferred for
277 The machine basic block's successors have to be specified before any of the
283 successors: %bb.1.then, %bb.2.else
290 The branch weights can be specified in brackets after the successor blocks.
291 The example below defines a block that has two successors with branch weights
297 successors: %bb.1.then(32), %bb.2.else(16)
304 The machine basic block's live in registers have to be specified before any of
312 The list of live in registers and successors can be empty. The language also
313 allows multiple live in register and successor lists - they are combined into
314 one list by the parser.
316 Miscellaneous Attributes
317 ^^^^^^^^^^^^^^^^^^^^^^^^
319 The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can be
320 specified in brackets after the block's definition:
324 bb.0.entry (address-taken):
328 bb.3(landing-pad, align 4):
331 .. TODO: Describe the way the reference to an unnamed LLVM IR block can be
337 A machine instruction is composed of a name,
338 :ref:`machine operands <machine-operands>`,
339 :ref:`instruction flags <instruction-flags>`, and machine memory operands.
341 The instruction's name is usually specified before the operands. The example
342 below shows an instance of the X86 ``RETQ`` instruction with a single machine
349 However, if the machine instruction has one or more explicitly defined register
350 operands, the instruction's name has to be specified after them. The example
351 below shows an instance of the AArch64 ``LDPXpost`` instruction with three
352 defined register operands:
356 %sp, %fp, %lr = LDPXpost %sp, 2
358 The instruction names are serialized using the exact definitions from the
359 target's ``*InstrInfo.td`` files, and they are case sensitive. This means that
360 similar instruction names like ``TSTri`` and ``tSTRi`` represent different
361 machine instructions.
363 .. _instruction-flags:
368 The flag ``frame-setup`` or ``frame-destroy`` can be specified before the
373 %fp = frame-setup ADDXri %sp, 0, 0
377 %x21, %x20 = frame-destroy LDPXi %sp
384 Registers are one of the key primitives in the machine instructions
385 serialization language. They are primarly used in the
386 :ref:`register machine operands <register-operands>`,
387 but they can also be used in a number of other places, like the
388 :ref:`basic block's live in list <bb-liveins>`.
390 The physical registers are identified by their name. They use the following
397 The example below shows three X86 physical registers:
405 The virtual registers are identified by their ID number. They use the following
418 The null registers are represented using an underscore ('``_``'). They can also be
419 represented using a '``%noreg``' named register, although the former syntax
422 .. _machine-operands:
427 There are seventeen different kinds of machine operands, and all of them, except
428 the ``MCSymbol`` operand, can be serialized. The ``MCSymbol`` operands are
429 just printed out - they can't be parsed back yet.
434 The immediate machine operands are untyped, 64-bit signed integers. The
435 example below shows an instance of the X86 ``MOV32ri`` instruction that has an
436 immediate machine operand ``-42``:
442 An immediate operand is also used to represent a subregister index when the
443 machine instruction has one of the following opcodes:
453 In case this is true, the Machine Operand is printed according to the target.
457 In AArch64RegisterInfo.td:
461 def sub_32 : SubRegIndex<32>;
463 If the third operand is an immediate with the value ``15`` (target-dependent
464 value), based on the instruction's opcode and the operand's index the operand
465 will be printed as ``%subreg.sub_32``:
469 %1:gpr64 = SUBREG_TO_REG 0, %0, %subreg.sub_32
471 For integers > 64bit, we use a special machine operand, ``MO_CImmediate``,
472 which stores the immediate in a ``ConstantInt`` using an ``APInt`` (LLVM's
473 arbitrary precision integers).
475 .. TODO: Describe the FPIMM immediate operands.
477 .. _register-operands:
482 The :ref:`register <registers>` primitive is used to represent the register
483 machine operands. The register operands can also have optional
484 :ref:`register flags <register-flags>`,
485 :ref:`a subregister index <subregister-indices>`,
486 and a reference to the tied register operand.
487 The full syntax of a register operand is shown below:
491 [<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def <tied-op>) ]
493 This example shows an instance of the X86 ``XOR32rr`` instruction that has
494 5 register operands with different register flags:
498 dead %eax = XOR32rr undef %eax, undef %eax, implicit-def dead %eflags, implicit-def %al
505 The table below shows all of the possible register flags along with the
506 corresponding internal ``llvm::RegState`` representation:
515 - ``RegState::Implicit``
518 - ``RegState::ImplicitDefine``
521 - ``RegState::Define``
530 - ``RegState::Undef``
533 - ``RegState::InternalRead``
535 * - ``early-clobber``
536 - ``RegState::EarlyClobber``
539 - ``RegState::Debug``
542 - ``RegState::Renamable``
544 .. _subregister-indices:
549 The register machine operands can reference a portion of a register by using
550 the subregister indices. The example below shows an instance of the ``COPY``
551 pseudo instruction that uses the X86 ``sub_8bit`` subregister index to copy 8
552 lower bits from the 32-bit virtual register 0 to the 8-bit virtual register 1:
556 %1 = COPY %0:sub_8bit
558 The names of the subregister indices are target specific, and are typically
559 defined in the target's ``*RegisterInfo.td`` file.
561 Constant Pool Indices
562 ^^^^^^^^^^^^^^^^^^^^^
564 A constant pool index (CPI) operand is printed using its index in the
565 function's ``MachineConstantPool`` and an offset.
567 For example, a CPI with the index 1 and offset 8:
571 %1:gr64 = MOV64ri %const.1 + 8
573 For a CPI with the index 0 and offset -12:
577 %1:gr64 = MOV64ri %const.0 - 12
579 A constant pool entry is bound to a LLVM IR ``Constant`` or a target-specific
580 ``MachineConstantPoolValue``. When serializing all the function's constants the
581 following format is used:
588 alignment: <alignment>
589 isTargetSpecific: <target-specific>
591 where ``<index>`` is a 32-bit unsigned integer, ``<value>`` is a `LLVM IR Constant
592 <https://www.llvm.org/docs/LangRef.html#constants>`_, alignment is a 32-bit
593 unsigned integer, and ``<target-specific>`` is either true or false.
601 value: 'double 3.250000e+00'
606 isTargetSpecific: true
608 Global Value Operands
609 ^^^^^^^^^^^^^^^^^^^^^
611 The global value machine operands reference the global values from the
612 :ref:`embedded LLVM IR module <embedded-module>`.
613 The example below shows an instance of the X86 ``MOV64rm`` instruction that has
614 a global value operand named ``G``:
618 %rax = MOV64rm %rip, 1, _, @G, _
620 The named global values are represented using an identifier with the '@' prefix.
621 If the identifier doesn't match the regular expression
622 `[-a-zA-Z$._][-a-zA-Z$._0-9]*`, then this identifier must be quoted.
624 The unnamed global values are represented using an unsigned numeric value with
625 the '@' prefix, like in the following examples: ``@0``, ``@989``.
627 Target-dependent Index Operands
628 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
630 A target index operand is a target-specific index and an offset. The
631 target-specific index is printed using target-specific names and a positive or
634 For example, the ``amdgpu-constdata-start`` is associated with the index ``0``
635 in the AMDGPU backend. So if we have a target index operand with the index 0
640 %sgpr2 = S_ADD_U32 _, target-index(amdgpu-constdata-start) + 8, implicit-def _, implicit-def _
642 Jump-table Index Operands
643 ^^^^^^^^^^^^^^^^^^^^^^^^^
645 A jump-table index operand with the index 0 is printed as following:
649 tBR_JTr killed %r0, %jump-table.0
651 A machine jump-table entry contains a list of ``MachineBasicBlocks``. When serializing all the function's jump-table entries, the following format is used:
659 blocks: [ <bbreference>, <bbreference>, ... ]
661 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>`.
671 blocks: [ '%bb.3', '%bb.9', '%bb.4.d3' ]
673 blocks: [ '%bb.7', '%bb.7', '%bb.4.d3', '%bb.5' ]
675 External Symbol Operands
676 ^^^^^^^^^^^^^^^^^^^^^^^^^
678 An external symbol operand is represented using an identifier with the ``$``
679 prefix. The identifier is surrounded with ""'s and escaped if it has any
680 special non-printable characters in it.
686 CALL64pcrel32 $__stack_chk_fail, csr_64, implicit %rsp, implicit-def %rsp
691 A MCSymbol operand is holding a pointer to a ``MCSymbol``. For the limitations
692 of this operand in MIR, see :ref:`limitations <limitations>`.
698 EH_LABEL <mcsymbol Ltmp1>
703 A CFI Index operand is holding an index into a per-function side-table,
704 ``MachineFunction::getFrameInstructions()``, which references all the frame
705 instructions in a ``MachineFunction``. A ``CFI_INSTRUCTION`` may look like it
706 contains multiple operands, but the only operand it contains is the CFI Index.
707 The other operands are tracked by the ``MCCFIInstruction`` object.
713 CFI_INSTRUCTION offset %w30, -16
715 which may be emitted later in the MC layer as:
724 An Intrinsic ID operand contains a generic intrinsic ID or a target-specific ID.
726 The syntax for the ``returnaddress`` intrinsic is:
730 %x0 = COPY intrinsic(@llvm.returnaddress)
735 A Predicate operand contains an IR predicate from ``CmpInst::Predicate``, like
738 For an int eq predicate ``ICMP_EQ``, the syntax is:
742 %2:gpr(s32) = G_ICMP intpred(eq), %0, %1
744 .. TODO: Describe the parsers default behaviour when optional YAML attributes
746 .. TODO: Describe the syntax for the bundled instructions.
747 .. TODO: Describe the syntax for virtual register YAML definitions.
748 .. TODO: Describe the machine function's YAML flag attributes.
749 .. TODO: Describe the syntax for the register mask machine operands.
750 .. TODO: Describe the frame information YAML mapping.
751 .. TODO: Describe the syntax of the stack object machine operands and their
753 .. TODO: Describe the syntax of the block address machine operands.
754 .. TODO: Describe the syntax of the metadata machine operands, and the
755 instructions debug location attribute.
756 .. TODO: Describe the syntax of the register live out machine operands.
757 .. TODO: Describe the syntax of the machine memory operands.