Machine IR (MIR) Format Reference Manual#

Warning

This is a work in progress.

Introduction#

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 machine specific intermediate representation.

The MIR serialization format is designed to be used for testing the code generation passes in LLVM.

Overview#

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 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.

MIR Testing Guide#

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-pass option in llc.

  • You can use llc’s -stop-after option with existing or new LLVM assembly tests and check the MIR output of a specific code generation pass.

Testing Individual Code Generation Passes#

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 -o 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 -o 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.

Simplifying MIR files#

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-mir option 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.

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 subclasses isn’t serialized at the moment.

  • 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.

  • 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 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.

High Level Structure#

Embedded Module#

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(ptr %x) {
   entry:
     %0 = load i32, ptr %x
     %1 = add i32 %0, 1
     store i32 %1, ptr %x
     ret i32 %1
   }

Machine Functions#

The remaining YAML documents contain the machine functions. This is an example of such a YAML document:

 ---
 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
 ...

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 attribute callSites is a representation of call site information which keeps track of call instructions and registers used to transfer call arguments.

Machine Instructions Format Reference#

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.

Machine Basic Blocks#

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.

Block References#

The machine basic blocks are identified by their ID numbers. Individual blocks are referenced using the following syntax:

%bb.<id>

Example:

%bb.0

The following syntax is also supported, but the former syntax is preferred for block references:

%bb.<id>[.<name>]

Example:

%bb.1.then

Successors#

The machine basic block’s successors must 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 parentheses 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)

Live In Registers#

The machine basic block’s live in registers have to be specified before any of its 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.

Miscellaneous Attributes#

The attributes IsAddressTaken, IsLandingPad, IsInlineAsmBrIndirectTarget and Alignment can be specified in parentheses after the block’s definition:

bb.0.entry (address-taken):
  <instructions>
bb.2.else (align 4):
  <instructions>
bb.3(landing-pad, align 4):
  <instructions>
bb.4 (inlineasm-br-indirect-target):
  <instructions>

Alignment is specified in bytes, and must be a power of two.

Machine Instructions#