Warning
This is a work in progress.
This document is a reference manual for the Machine IR (MIR) serialization format. MIR is a human readable serialization format that is used to represent LLVM's :ref:`machine specific intermediate representation <machine code representation>`.
The MIR serialization format is designed to be used for testing the code generation passes in LLVM.
The MIR serialization format uses a YAML container. YAML is a standard data serialization language, and the full YAML language spec can be read at yaml.org.
A MIR file is split up 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.
You can use the MIR format for testing in two different ways:
- You can write MIR tests that invoke a single code generation pass using the
-run-passoption in llc. - You can use llc's
-stop-afteroption with existing or new LLVM assembly tests and check the MIR output of a specific code generation pass.
The -run-pass option in llc allows you to create MIR tests that invoke just
a single code generation pass. When this option is used, llc will parse an
input MIR file, run the specified code generation pass(es), and output the
resulting MIR code.
You can generate an input MIR file for the test by using the -stop-after or
-stop-before option in llc. For example, if you would like to write a test
for the post register allocation pseudo instruction expansion pass, you can
specify the machine copy propagation pass in the -stop-after option, as it
runs just before the pass that we are trying to test:
llc -stop-after=machine-cp bug-trigger.ll > test.mir
If the same pass is run multiple times, a run index can be included after the name with a comma.
llc -stop-after=dead-mi-elimination,1 bug-trigger.ll > test.mir
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 embedded LLVM IR module.
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-miroption with llc. - Machine function attributes often have default values or the test works just as well with default values. Typical candidates for this are: alignment:, exposesReturnsTwice, legalized, regBankSelected, selected. The whole frameInfo section is often unnecessary if there is no special frame usage in the function. tracksRegLiveness on the other hand is often necessary for some passes that care about block livein lists.
- The (global) liveins: list is typically only interesting for early instruction selection passes and can be removed when testing later passes. The per-block liveins: on the other hand are necessary if tracksRegLiveness is true.
- Branch probability data in block successors: lists can be dropped if the test doesn't depend on it. Example: successors: %bb.1(0x40000000), %bb.2(0x40000000) can be replaced with successors: %bb.1, %bb.2.
- MIR code contains a whole IR module. This is necessary because there are no equivalents in MIR for global variables, references to external functions, function attributes, metadata, debug info. Instead some MIR data references the IR constructs. You can often remove them if the test doesn't depend on them.
- Alias Analysis is performed on IR values. These are referenced by memory operands in MIR. Example: :: (load 8 from %ir.foobar, !alias.scope !9). 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 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 }.
- 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 IR functions automatically in this case.
Currently the MIR format has several limitations in terms of which state it can serialize:
- The target-specific state in the target-specific
MachineFunctionInfosubclasses isn't serialized at the moment. - The target-specific
MachineConstantPoolValuesubclasses (in the ARM and SystemZ backends) aren't serialized at the moment. - The
MCSymbolmachine operands don't support temporary or local symbols. - A lot of the state in
MachineModuleInfoisn't serialized - only the CFI instructions and the variable debug information from MMI is 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
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.
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:
define i32 @inc(i32* %x) {
entry:
%0 = load i32, i32* %x
%1 = add i32 %0, 1
store i32 %1, i32* %x
ret i32 %1
}The remaining YAML documents contain the machine functions. This is an example of such YAML document:
---
name: inc
tracksRegLiveness: true
liveins:
- { reg: '$rdi' }
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
RETQ $eax
...
The document above consists of attributes that represent the various properties and data structures in a machine function.
The attribute name is required, and its value should be identical to the
name of a function that this machine function is based on.
The attribute body is a YAML block literal string. Its value represents
the function's machine basic blocks and their machine instructions.
The machine basic blocks and their instructions are represented using a custom, human readable serialization language. This language is used in the YAML block literal string that corresponds to the machine function's body.
A source string that uses this language contains a list of machine basic blocks, which are described in the section below.
A machine basic block is defined in a single block definition source construct that contains the block's ID. The example below defines two blocks that have an ID of zero and one:
bb.0:
<instructions>
bb.1:
<instructions>
A machine basic block can also have a name. It should be specified after the ID in the block's definition:
bb.0.entry: ; This block's name is "entry"
<instructions>
The block's name should be identical to the name of the IR block that this machine block is based on.
The machine basic blocks are identified by their ID numbers. Individual blocks are referenced using the following syntax:
%bb.<id>
Example:
%bb.0The following syntax is also supported, but the former syntax is preferred for block references:
%bb.<id>[.<name>]
Example:
%bb.1.thenThe machine basic block's successors have to be specified before any of the instructions:
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:
bb.0.entry:
successors: %bb.1.then(32), %bb.2.else(16)
The machine basic block's live in registers have to be specified before any of the instructions:
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.
The attributes IsAddressTaken, IsLandingPad and Alignment can be
specified in brackets after the block's definition:
bb.0.entry (address-taken):
<instructions>
bb.2.else (align 4):
<instructions>
bb.3(landing-pad, align 4):
<instructions>
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:
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:
$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.
The flag frame-setup or frame-destroy can be specified before the
instruction's name:
$fp = frame-setup ADDXri $sp, 0, 0
$x21, $x20 = frame-destroy LDPXi $sp
The syntax for bundled instructions is the following:
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.
Registers are one of the key primitives in the machine instructions 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 :ref:`basic block's live in list <bb-liveins>`.
The physical registers are identified by their name and by the '$' prefix sigil. They use the following syntax:
$<name>
The example below shows three X86 physical registers:
$eax
$r15
$eflags
The virtual registers are identified by their ID number and by the '%' sigil. They use the following syntax:
%<id>
Example:
%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.
There are seventeen different kinds of machine operands, and all of them can be serialized.
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:
$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_SUBREGINSERT_SUBREGREG_SEQUENCESUBREG_TO_REG
In case this is true, the Machine Operand is printed according to the target.
For example:
In AArch64RegisterInfo.td:
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:
%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).
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:
[<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:
dead $eax = XOR32rr undef $eax, undef $eax, implicit-def dead $eflags, implicit-def $al
The table below shows all of the possible register flags along with the
corresponding internal llvm::RegState representation:
| Flag | Internal Value |
|---|---|
implicit |
RegState::Implicit |
implicit-def |
RegState::ImplicitDefine |
def |
RegState::Define |
dead |
RegState::Dead |
killed |
RegState::Kill |
undef |
RegState::Undef |
internal |
RegState::InternalRead |
early-clobber |
RegState::EarlyClobber |
debug-use |
RegState::Debug |
renamable |
RegState::Renamable |
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:
%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.
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:
%1:gr64 = MOV64ri %const.1 + 8
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
following format is used:
constants:
- id: <index>
value: <value>
alignment: <alignment>
isTargetSpecific: <target-specific>
where <index> is a 32-bit unsigned integer, <value> is a LLVM IR Constant, alignment is a 32-bit
unsigned integer, and <target-specific> is either true or false.
Example:
constants:
- id: 0
value: 'double 3.250000e+00'
alignment: 8
- id: 1
value: 'g-(LPC0+8)'
alignment: 4
isTargetSpecific: true
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:
$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.
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:
$sgpr2 = S_ADD_U32 _, target-index(amdgpu-constdata-start) + 8, implicit-def _, implicit-def _
A jump-table index operand with the index 0 is printed as following:
tBR_JTr killed $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:
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:
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' ]
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:
CALL64pcrel32 &__stack_chk_fail, csr_64, implicit $rsp, implicit-def $rsp
A MCSymbol operand is holding a pointer to a MCSymbol. For the limitations
of this operand in MIR, see :ref:`limitations <limitations>`.
The syntax is:
EH_LABEL <mcsymbol Ltmp1>
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:
CFI_INSTRUCTION offset $w30, -16
which may be emitted later in the MC layer as:
.cfi_offset w30, -16
An Intrinsic ID operand contains a generic intrinsic ID or a target-specific ID.
The syntax for the returnaddress intrinsic is:
$x0 = COPY intrinsic(@llvm.returnaddress)
A Predicate operand contains an IR predicate from CmpInst::Predicate, like
ICMP_EQ, etc.
For an int eq predicate ICMP_EQ, the syntax is:
%2:gpr(s32) = G_ICMP intpred(eq), %0, %1