Alex Lorenz | 3d31177 | 2015-08-06 22:55:19 +0000 | [diff] [blame] | 1 | ======================================== |
| 2 | Machine IR (MIR) Format Reference Manual |
| 3 | ======================================== |
| 4 | |
| 5 | .. contents:: |
| 6 | :local: |
| 7 | |
| 8 | .. warning:: |
| 9 | This is a work in progress. |
| 10 | |
| 11 | Introduction |
| 12 | ============ |
| 13 | |
| 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>`. |
| 18 | |
| 19 | The MIR serialization format is designed to be used for testing the code |
| 20 | generation passes in LLVM. |
| 21 | |
| 22 | Overview |
| 23 | ======== |
| 24 | |
| 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 |
| 27 | `yaml.org |
| 28 | <http://www.yaml.org/spec/1.2/spec.html#Introduction>`_. |
| 29 | |
| 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. |
| 33 | |
| 34 | .. _YAML documents: http://www.yaml.org/spec/1.2/spec.html#id2800132 |
| 35 | |
| 36 | High Level Structure |
| 37 | ==================== |
| 38 | |
| 39 | Embedded Module |
| 40 | --------------- |
| 41 | |
| 42 | When the first YAML document contains a `YAML block literal string`_, the MIR |
| 43 | parser will treat this string as an LLVM assembly language string that |
| 44 | represents an embedded LLVM IR module. |
| 45 | Here is an example of a YAML document that contains an LLVM module: |
| 46 | |
| 47 | .. code-block:: llvm |
| 48 | |
| 49 | --- | |
| 50 | define i32 @inc(i32* %x) { |
| 51 | entry: |
| 52 | %0 = load i32, i32* %x |
| 53 | %1 = add i32 %0, 1 |
| 54 | store i32 %1, i32* %x |
| 55 | ret i32 %1 |
| 56 | } |
| 57 | ... |
| 58 | |
| 59 | .. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688 |
| 60 | |
| 61 | Machine Functions |
| 62 | ----------------- |
| 63 | |
| 64 | The remaining YAML documents contain the machine functions. This is an example |
| 65 | of such YAML document: |
| 66 | |
Alex Lorenz | 9846167 | 2015-08-14 00:36:10 +0000 | [diff] [blame] | 67 | .. code-block:: llvm |
Alex Lorenz | 3d31177 | 2015-08-06 22:55:19 +0000 | [diff] [blame] | 68 | |
| 69 | --- |
| 70 | name: inc |
| 71 | tracksRegLiveness: true |
| 72 | liveins: |
| 73 | - { reg: '%rdi' } |
Alex Lorenz | 9846167 | 2015-08-14 00:36:10 +0000 | [diff] [blame] | 74 | body: | |
| 75 | bb.0.entry: |
| 76 | liveins: %rdi |
| 77 | |
| 78 | %eax = MOV32rm %rdi, 1, _, 0, _ |
| 79 | %eax = INC32r killed %eax, implicit-def dead %eflags |
| 80 | MOV32mr killed %rdi, 1, _, 0, _, %eax |
| 81 | RETQ %eax |
Alex Lorenz | 3d31177 | 2015-08-06 22:55:19 +0000 | [diff] [blame] | 82 | ... |
| 83 | |
| 84 | The document above consists of attributes that represent the various |
| 85 | properties and data structures in a machine function. |
| 86 | |
| 87 | The attribute ``name`` is required, and its value should be identical to the |
| 88 | name of a function that this machine function is based on. |
| 89 | |
Alex Lorenz | 9846167 | 2015-08-14 00:36:10 +0000 | [diff] [blame] | 90 | The attribute ``body`` is a `YAML block literal string`_. Its value represents |
| 91 | the function's machine basic blocks and their machine instructions. |
Alex Lorenz | 3d31177 | 2015-08-06 22:55:19 +0000 | [diff] [blame] | 92 | |
Alex Lorenz | 3a4a60c | 2015-08-15 01:06:06 +0000 | [diff] [blame] | 93 | Machine Instructions Format Reference |
| 94 | ===================================== |
| 95 | |
| 96 | The machine basic blocks and their instructions are represented using a custom, |
| 97 | human readable serialization language. This language is used in the |
| 98 | `YAML block literal string`_ that corresponds to the machine function's body. |
| 99 | |
| 100 | A source string that uses this language contains a list of machine basic |
| 101 | blocks, which are described in the section below. |
| 102 | |
| 103 | Machine Basic Blocks |
| 104 | -------------------- |
| 105 | |
| 106 | A machine basic block is defined in a single block definition source construct |
| 107 | that contains the block's ID. |
| 108 | The example below defines two blocks that have an ID of zero and one: |
| 109 | |
| 110 | .. code-block:: llvm |
| 111 | |
| 112 | bb.0: |
| 113 | <instructions> |
| 114 | bb.1: |
| 115 | <instructions> |
| 116 | |
| 117 | A machine basic block can also have a name. It should be specified after the ID |
| 118 | in the block's definition: |
| 119 | |
| 120 | .. code-block:: llvm |
| 121 | |
| 122 | bb.0.entry: ; This block's name is "entry" |
| 123 | <instructions> |
| 124 | |
| 125 | The block's name should be identical to the name of the IR block that this |
| 126 | machine block is based on. |
| 127 | |
| 128 | Block References |
| 129 | ^^^^^^^^^^^^^^^^ |
| 130 | |
| 131 | The machine basic blocks are identified by their ID numbers. Individual |
| 132 | blocks are referenced using the following syntax: |
| 133 | |
| 134 | .. code-block:: llvm |
| 135 | |
| 136 | %bb.<id>[.<name>] |
| 137 | |
| 138 | Examples: |
| 139 | |
| 140 | .. code-block:: llvm |
| 141 | |
| 142 | %bb.0 |
| 143 | %bb.1.then |
| 144 | |
| 145 | Successors |
| 146 | ^^^^^^^^^^ |
| 147 | |
| 148 | The machine basic block's successors have to be specified before any of the |
| 149 | instructions: |
| 150 | |
| 151 | .. code-block:: llvm |
| 152 | |
| 153 | bb.0.entry: |
| 154 | successors: %bb.1.then, %bb.2.else |
| 155 | <instructions> |
| 156 | bb.1.then: |
| 157 | <instructions> |
| 158 | bb.2.else: |
| 159 | <instructions> |
| 160 | |
| 161 | The branch weights can be specified in brackets after the successor blocks. |
| 162 | The example below defines a block that has two successors with branch weights |
| 163 | of 32 and 16: |
| 164 | |
| 165 | .. code-block:: llvm |
| 166 | |
| 167 | bb.0.entry: |
| 168 | successors: %bb.1.then(32), %bb.2.else(16) |
| 169 | |
Alex Lorenz | b981d37 | 2015-08-21 21:17:01 +0000 | [diff] [blame^] | 170 | .. _bb-liveins: |
| 171 | |
Alex Lorenz | 3a4a60c | 2015-08-15 01:06:06 +0000 | [diff] [blame] | 172 | Live In Registers |
| 173 | ^^^^^^^^^^^^^^^^^ |
| 174 | |
| 175 | The machine basic block's live in registers have to be specified before any of |
| 176 | the instructions: |
| 177 | |
| 178 | .. code-block:: llvm |
| 179 | |
| 180 | bb.0.entry: |
| 181 | liveins: %edi, %esi |
| 182 | |
| 183 | The list of live in registers and successors can be empty. The language also |
| 184 | allows multiple live in register and successor lists - they are combined into |
| 185 | one list by the parser. |
| 186 | |
| 187 | Miscellaneous Attributes |
| 188 | ^^^^^^^^^^^^^^^^^^^^^^^^ |
| 189 | |
| 190 | The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can be |
| 191 | specified in brackets after the block's definition: |
| 192 | |
| 193 | .. code-block:: llvm |
| 194 | |
| 195 | bb.0.entry (address-taken): |
| 196 | <instructions> |
| 197 | bb.2.else (align 4): |
| 198 | <instructions> |
| 199 | bb.3(landing-pad, align 4): |
| 200 | <instructions> |
| 201 | |
| 202 | .. TODO: Describe the way the reference to an unnamed LLVM IR block can be |
| 203 | preserved. |
| 204 | |
Alex Lorenz | 8eadc3f | 2015-08-21 17:26:38 +0000 | [diff] [blame] | 205 | Machine Instructions |
| 206 | -------------------- |
| 207 | |
Alex Lorenz | b981d37 | 2015-08-21 21:17:01 +0000 | [diff] [blame^] | 208 | A machine instruction is composed of a name, |
| 209 | :ref:`machine operands <machine-operands>`, |
Alex Lorenz | 8eadc3f | 2015-08-21 17:26:38 +0000 | [diff] [blame] | 210 | :ref:`instruction flags <instruction-flags>`, and machine memory operands. |
| 211 | |
| 212 | The instruction's name is usually specified before the operands. The example |
| 213 | below shows an instance of the X86 ``RETQ`` instruction with a single machine |
| 214 | operand: |
| 215 | |
| 216 | .. code-block:: llvm |
| 217 | |
| 218 | RETQ %eax |
| 219 | |
| 220 | However, if the machine instruction has one or more explicitly defined register |
| 221 | operands, the instruction's name has to be specified after them. The example |
| 222 | below shows an instance of the AArch64 ``LDPXpost`` instruction with three |
| 223 | defined register operands: |
| 224 | |
| 225 | .. code-block:: llvm |
| 226 | |
| 227 | %sp, %fp, %lr = LDPXpost %sp, 2 |
| 228 | |
| 229 | The instruction names are serialized using the exact definitions from the |
| 230 | target's ``*InstrInfo.td`` files, and they are case sensitive. This means that |
| 231 | similar instruction names like ``TSTri`` and ``tSTRi`` represent different |
| 232 | machine instructions. |
| 233 | |
| 234 | .. _instruction-flags: |
| 235 | |
| 236 | Instruction Flags |
| 237 | ^^^^^^^^^^^^^^^^^ |
| 238 | |
| 239 | The flag ``frame-setup`` can be specified before the instruction's name: |
| 240 | |
| 241 | .. code-block:: llvm |
| 242 | |
| 243 | %fp = frame-setup ADDXri %sp, 0, 0 |
| 244 | |
Alex Lorenz | b981d37 | 2015-08-21 21:17:01 +0000 | [diff] [blame^] | 245 | .. _registers: |
| 246 | |
| 247 | Registers |
| 248 | --------- |
| 249 | |
| 250 | Registers are one of the key primitives in the machine instructions |
| 251 | serialization language. They are primarly used in the |
| 252 | :ref:`register machine operands <register-operands>`, |
| 253 | but they can also be used in a number of other places, like the |
| 254 | :ref:`basic block's live in list <bb-liveins>`. |
| 255 | |
| 256 | The physical registers are identified by their name. They use the following |
| 257 | syntax: |
| 258 | |
| 259 | .. code-block:: llvm |
| 260 | |
| 261 | %<name> |
| 262 | |
| 263 | The example below shows three X86 physical registers: |
| 264 | |
| 265 | .. code-block:: llvm |
| 266 | |
| 267 | %eax |
| 268 | %r15 |
| 269 | %eflags |
| 270 | |
| 271 | The virtual registers are identified by their ID number. They use the following |
| 272 | syntax: |
| 273 | |
| 274 | .. code-block:: llvm |
| 275 | |
| 276 | %<id> |
| 277 | |
| 278 | Example: |
| 279 | |
| 280 | .. code-block:: llvm |
| 281 | |
| 282 | %0 |
| 283 | |
| 284 | The null registers are represented using an underscore ('``_``'). They can also be |
| 285 | represented using a '``%noreg``' named register, although the former syntax |
| 286 | is preferred. |
| 287 | |
| 288 | .. _machine-operands: |
| 289 | |
| 290 | Machine Operands |
| 291 | ---------------- |
| 292 | |
| 293 | There are seventeen different kinds of machine operands, and all of them, except |
| 294 | the ``MCSymbol`` operand, can be serialized. The ``MCSymbol`` operands are |
| 295 | just printed out - they can't be parsed back yet. |
| 296 | |
| 297 | Immediate Operands |
| 298 | ^^^^^^^^^^^^^^^^^^ |
| 299 | |
| 300 | The immediate machine operands are untyped, 64-bit signed integers. The |
| 301 | example below shows an instance of the X86 ``MOV32ri`` instruction that has an |
| 302 | immediate machine operand ``-42``: |
| 303 | |
| 304 | .. code-block:: llvm |
| 305 | |
| 306 | %eax = MOV32ri -42 |
| 307 | |
| 308 | .. TODO: Describe the CIMM (Rare) and FPIMM immediate operands. |
| 309 | |
| 310 | .. _register-operands: |
| 311 | |
| 312 | Register Operands |
| 313 | ^^^^^^^^^^^^^^^^^ |
| 314 | |
| 315 | The :ref:`register <registers>` primitive is used to represent the register |
| 316 | machine operands. The register operands can also have optional |
| 317 | :ref:`register flags <register-flags>`, |
| 318 | a subregister index, and a reference to the tied register operand. |
| 319 | The full syntax of a register operand is shown below: |
| 320 | |
| 321 | .. code-block:: llvm |
| 322 | |
| 323 | [<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def <tied-op>) ] |
| 324 | |
| 325 | This example shows an instance of the X86 ``XOR32rr`` instruction that has |
| 326 | 5 register operands with different register flags: |
| 327 | |
| 328 | .. code-block:: llvm |
| 329 | |
| 330 | dead %eax = XOR32rr undef %eax, undef %eax, implicit-def dead %eflags, implicit-def %al |
| 331 | |
| 332 | .. _register-flags: |
| 333 | |
| 334 | Register Flags |
| 335 | ~~~~~~~~~~~~~~ |
| 336 | |
| 337 | The table below shows all of the possible register flags along with the |
| 338 | corresponding internal ``llvm::RegState`` representation: |
| 339 | |
| 340 | .. list-table:: |
| 341 | :header-rows: 1 |
| 342 | |
| 343 | * - Flag |
| 344 | - Internal Value |
| 345 | |
| 346 | * - ``implicit`` |
| 347 | - ``RegState::Implicit`` |
| 348 | |
| 349 | * - ``implicit-def`` |
| 350 | - ``RegState::ImplicitDefine`` |
| 351 | |
| 352 | * - ``def`` |
| 353 | - ``RegState::Define`` |
| 354 | |
| 355 | * - ``dead`` |
| 356 | - ``RegState::Dead`` |
| 357 | |
| 358 | * - ``killed`` |
| 359 | - ``RegState::Kill`` |
| 360 | |
| 361 | * - ``undef`` |
| 362 | - ``RegState::Undef`` |
| 363 | |
| 364 | * - ``internal`` |
| 365 | - ``RegState::InternalRead`` |
| 366 | |
| 367 | * - ``early-clobber`` |
| 368 | - ``RegState::EarlyClobber`` |
| 369 | |
| 370 | * - ``debug-use`` |
| 371 | - ``RegState::Debug`` |
Alex Lorenz | 3a4a60c | 2015-08-15 01:06:06 +0000 | [diff] [blame] | 372 | |
Alex Lorenz | 3d31177 | 2015-08-06 22:55:19 +0000 | [diff] [blame] | 373 | .. TODO: Describe the parsers default behaviour when optional YAML attributes |
| 374 | are missing. |
Alex Lorenz | 8eadc3f | 2015-08-21 17:26:38 +0000 | [diff] [blame] | 375 | .. TODO: Describe the syntax for the bundled instructions. |
Alex Lorenz | b981d37 | 2015-08-21 21:17:01 +0000 | [diff] [blame^] | 376 | .. TODO: Describe the syntax for virtual register YAML definitions. |
| 377 | .. TODO: Describe the syntax of the subregisters. |
Alex Lorenz | 3d31177 | 2015-08-06 22:55:19 +0000 | [diff] [blame] | 378 | .. TODO: Describe the machine function's YAML flag attributes. |
Alex Lorenz | 3d31177 | 2015-08-06 22:55:19 +0000 | [diff] [blame] | 379 | .. TODO: Describe the syntax for the global value, external symbol and register |
| 380 | mask machine operands. |
| 381 | .. TODO: Describe the frame information YAML mapping. |
| 382 | .. TODO: Describe the syntax of the stack object machine operands and their |
| 383 | YAML definitions. |
| 384 | .. TODO: Describe the syntax of the constant pool machine operands and their |
| 385 | YAML definitions. |
| 386 | .. TODO: Describe the syntax of the jump table machine operands and their |
| 387 | YAML definitions. |
| 388 | .. TODO: Describe the syntax of the block address machine operands. |
| 389 | .. TODO: Describe the syntax of the CFI index machine operands. |
| 390 | .. TODO: Describe the syntax of the metadata machine operands, and the |
| 391 | instructions debug location attribute. |
| 392 | .. TODO: Describe the syntax of the target index machine operands. |
| 393 | .. TODO: Describe the syntax of the register live out machine operands. |
| 394 | .. TODO: Describe the syntax of the machine memory operands. |