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
51 just a single code generation pass. When this option is used, llc will parse
52 an input MIR file, run the specified code generation pass, and print the
53 resulting MIR to the standard output stream.
55 You can generate an input MIR file for the test by using the ``stop-after``
56 option in llc. For example, if you would like to write a test for the
57 post register allocation pseudo instruction expansion pass, you can specify
58 the machine copy propagation pass in the ``stop-after`` option, as it runs
59 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 -run-pass postrapseudos -march=x86-64 %s -o /dev/null | FileCheck %s``
70 The MIR files are target dependent, so they have to be placed in the target
71 specific test directories. They also need to specify a target triple or a
72 target architecture either in the run line or in the embedded LLVM IR module.
77 Currently the MIR format has several limitations in terms of which state it
80 - The target-specific state in the target-specific ``MachineFunctionInfo``
81 subclasses isn't serialized at the moment.
83 - The target-specific ``MachineConstantPoolValue`` subclasses (in the ARM and
84 SystemZ backends) aren't serialized at the moment.
86 - The ``MCSymbol`` machine operands are only printed, they can't be parsed.
88 - A lot of the state in ``MachineModuleInfo`` isn't serialized - only the CFI
89 instructions and the variable debug information from MMI is serialized right
92 These limitations impose restrictions on what you can test with the MIR format.
93 For now, tests that would like to test some behaviour that depends on the state
94 of certain ``MCSymbol`` operands or the exception handling state in MMI, can't
95 use the MIR format. As well as that, tests that test some behaviour that
96 depends on the state of the target specific ``MachineFunctionInfo`` or
97 ``MachineConstantPoolValue`` subclasses can't use the MIR format at the moment.
105 When the first YAML document contains a `YAML block literal string`_, the MIR
106 parser will treat this string as an LLVM assembly language string that
107 represents an embedded LLVM IR module.
108 Here is an example of a YAML document that contains an LLVM module:
113 define i32 @inc(i32* %x) {
115 %0 = load i32, i32* %x
117 store i32 %1, i32* %x
122 .. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688
127 The remaining YAML documents contain the machine functions. This is an example
128 of such YAML document:
134 tracksRegLiveness: true
141 %eax = MOV32rm %rdi, 1, _, 0, _
142 %eax = INC32r killed %eax, implicit-def dead %eflags
143 MOV32mr killed %rdi, 1, _, 0, _, %eax
147 The document above consists of attributes that represent the various
148 properties and data structures in a machine function.
150 The attribute ``name`` is required, and its value should be identical to the
151 name of a function that this machine function is based on.
153 The attribute ``body`` is a `YAML block literal string`_. Its value represents
154 the function's machine basic blocks and their machine instructions.
156 Machine Instructions Format Reference
157 =====================================
159 The machine basic blocks and their instructions are represented using a custom,
160 human readable serialization language. This language is used in the
161 `YAML block literal string`_ that corresponds to the machine function's body.
163 A source string that uses this language contains a list of machine basic
164 blocks, which are described in the section below.
169 A machine basic block is defined in a single block definition source construct
170 that contains the block's ID.
171 The example below defines two blocks that have an ID of zero and one:
180 A machine basic block can also have a name. It should be specified after the ID
181 in the block's definition:
185 bb.0.entry: ; This block's name is "entry"
188 The block's name should be identical to the name of the IR block that this
189 machine block is based on.
194 The machine basic blocks are identified by their ID numbers. Individual
195 blocks are referenced using the following syntax:
211 The machine basic block's successors have to be specified before any of the
217 successors: %bb.1.then, %bb.2.else
224 The branch weights can be specified in brackets after the successor blocks.
225 The example below defines a block that has two successors with branch weights
231 successors: %bb.1.then(32), %bb.2.else(16)
238 The machine basic block's live in registers have to be specified before any of
246 The list of live in registers and successors can be empty. The language also
247 allows multiple live in register and successor lists - they are combined into
248 one list by the parser.
250 Miscellaneous Attributes
251 ^^^^^^^^^^^^^^^^^^^^^^^^
253 The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can be
254 specified in brackets after the block's definition:
258 bb.0.entry (address-taken):
262 bb.3(landing-pad, align 4):
265 .. TODO: Describe the way the reference to an unnamed LLVM IR block can be
271 A machine instruction is composed of a name,
272 :ref:`machine operands <machine-operands>`,
273 :ref:`instruction flags <instruction-flags>`, and machine memory operands.
275 The instruction's name is usually specified before the operands. The example
276 below shows an instance of the X86 ``RETQ`` instruction with a single machine
283 However, if the machine instruction has one or more explicitly defined register
284 operands, the instruction's name has to be specified after them. The example
285 below shows an instance of the AArch64 ``LDPXpost`` instruction with three
286 defined register operands:
290 %sp, %fp, %lr = LDPXpost %sp, 2
292 The instruction names are serialized using the exact definitions from the
293 target's ``*InstrInfo.td`` files, and they are case sensitive. This means that
294 similar instruction names like ``TSTri`` and ``tSTRi`` represent different
295 machine instructions.
297 .. _instruction-flags:
302 The flag ``frame-setup`` can be specified before the instruction's name:
306 %fp = frame-setup ADDXri %sp, 0, 0
313 Registers are one of the key primitives in the machine instructions
314 serialization language. They are primarly used in the
315 :ref:`register machine operands <register-operands>`,
316 but they can also be used in a number of other places, like the
317 :ref:`basic block's live in list <bb-liveins>`.
319 The physical registers are identified by their name. They use the following
326 The example below shows three X86 physical registers:
334 The virtual registers are identified by their ID number. They use the following
347 The null registers are represented using an underscore ('``_``'). They can also be
348 represented using a '``%noreg``' named register, although the former syntax
351 .. _machine-operands:
356 There are seventeen different kinds of machine operands, and all of them, except
357 the ``MCSymbol`` operand, can be serialized. The ``MCSymbol`` operands are
358 just printed out - they can't be parsed back yet.
363 The immediate machine operands are untyped, 64-bit signed integers. The
364 example below shows an instance of the X86 ``MOV32ri`` instruction that has an
365 immediate machine operand ``-42``:
371 .. TODO: Describe the CIMM (Rare) and FPIMM immediate operands.
373 .. _register-operands:
378 The :ref:`register <registers>` primitive is used to represent the register
379 machine operands. The register operands can also have optional
380 :ref:`register flags <register-flags>`,
381 a subregister index, and a reference to the tied register operand.
382 The full syntax of a register operand is shown below:
386 [<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def <tied-op>) ]
388 This example shows an instance of the X86 ``XOR32rr`` instruction that has
389 5 register operands with different register flags:
393 dead %eax = XOR32rr undef %eax, undef %eax, implicit-def dead %eflags, implicit-def %al
400 The table below shows all of the possible register flags along with the
401 corresponding internal ``llvm::RegState`` representation:
410 - ``RegState::Implicit``
413 - ``RegState::ImplicitDefine``
416 - ``RegState::Define``
425 - ``RegState::Undef``
428 - ``RegState::InternalRead``
430 * - ``early-clobber``
431 - ``RegState::EarlyClobber``
434 - ``RegState::Debug``
436 .. TODO: Describe the parsers default behaviour when optional YAML attributes
438 .. TODO: Describe the syntax for the bundled instructions.
439 .. TODO: Describe the syntax for virtual register YAML definitions.
440 .. TODO: Describe the syntax of the subregisters.
441 .. TODO: Describe the machine function's YAML flag attributes.
442 .. TODO: Describe the syntax for the global value, external symbol and register
443 mask machine operands.
444 .. TODO: Describe the frame information YAML mapping.
445 .. TODO: Describe the syntax of the stack object machine operands and their
447 .. TODO: Describe the syntax of the constant pool machine operands and their
449 .. TODO: Describe the syntax of the jump table machine operands and their
451 .. TODO: Describe the syntax of the block address machine operands.
452 .. TODO: Describe the syntax of the CFI index machine operands.
453 .. TODO: Describe the syntax of the metadata machine operands, and the
454 instructions debug location attribute.
455 .. TODO: Describe the syntax of the target index machine operands.
456 .. TODO: Describe the syntax of the register live out machine operands.
457 .. TODO: Describe the syntax of the machine memory operands.