blob: 1a8525baf6cb68b5e2b2d15537543deddc752ae7 [file] [log] [blame]
Alex Lorenz3d311772015-08-06 22:55:19 +00001========================================
2Machine IR (MIR) Format Reference Manual
3========================================
4
5.. contents::
6 :local:
7
8.. warning::
9 This is a work in progress.
10
11Introduction
12============
13
14This document is a reference manual for the Machine IR (MIR) serialization
15format. MIR is a human readable serialization format that is used to represent
16LLVM's :ref:`machine specific intermediate representation
17<machine code representation>`.
18
19The MIR serialization format is designed to be used for testing the code
20generation passes in LLVM.
21
22Overview
23========
24
25The MIR serialization format uses a YAML container. YAML is a standard
26data 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
30A MIR file is split up into a series of `YAML documents`_. The first document
31can contain an optional embedded LLVM IR module, and the rest of the documents
32contain the serialized machine functions.
33
34.. _YAML documents: http://www.yaml.org/spec/1.2/spec.html#id2800132
35
36High Level Structure
37====================
38
39Embedded Module
40---------------
41
42When the first YAML document contains a `YAML block literal string`_, the MIR
43parser will treat this string as an LLVM assembly language string that
44represents an embedded LLVM IR module.
45Here 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
61Machine Functions
62-----------------
63
64The remaining YAML documents contain the machine functions. This is an example
65of such YAML document:
66
Alex Lorenz98461672015-08-14 00:36:10 +000067.. code-block:: llvm
Alex Lorenz3d311772015-08-06 22:55:19 +000068
69 ---
70 name: inc
71 tracksRegLiveness: true
72 liveins:
73 - { reg: '%rdi' }
Alex Lorenz98461672015-08-14 00:36:10 +000074 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 Lorenz3d311772015-08-06 22:55:19 +000082 ...
83
84The document above consists of attributes that represent the various
85properties and data structures in a machine function.
86
87The attribute ``name`` is required, and its value should be identical to the
88name of a function that this machine function is based on.
89
Alex Lorenz98461672015-08-14 00:36:10 +000090The attribute ``body`` is a `YAML block literal string`_. Its value represents
91the function's machine basic blocks and their machine instructions.
Alex Lorenz3d311772015-08-06 22:55:19 +000092
Alex Lorenz3a4a60c2015-08-15 01:06:06 +000093Machine Instructions Format Reference
94=====================================
95
96The machine basic blocks and their instructions are represented using a custom,
97human readable serialization language. This language is used in the
98`YAML block literal string`_ that corresponds to the machine function's body.
99
100A source string that uses this language contains a list of machine basic
101blocks, which are described in the section below.
102
103Machine Basic Blocks
104--------------------
105
106A machine basic block is defined in a single block definition source construct
107that contains the block's ID.
108The 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
117A machine basic block can also have a name. It should be specified after the ID
118in the block's definition:
119
120.. code-block:: llvm
121
122 bb.0.entry: ; This block's name is "entry"
123 <instructions>
124
125The block's name should be identical to the name of the IR block that this
126machine block is based on.
127
128Block References
129^^^^^^^^^^^^^^^^
130
131The machine basic blocks are identified by their ID numbers. Individual
132blocks are referenced using the following syntax:
133
134.. code-block:: llvm
135
136 %bb.<id>[.<name>]
137
138Examples:
139
140.. code-block:: llvm
141
142 %bb.0
143 %bb.1.then
144
145Successors
146^^^^^^^^^^
147
148The machine basic block's successors have to be specified before any of the
149instructions:
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
161The branch weights can be specified in brackets after the successor blocks.
162The example below defines a block that has two successors with branch weights
163of 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 Lorenzb981d372015-08-21 21:17:01 +0000170.. _bb-liveins:
171
Alex Lorenz3a4a60c2015-08-15 01:06:06 +0000172Live In Registers
173^^^^^^^^^^^^^^^^^
174
175The machine basic block's live in registers have to be specified before any of
176the instructions:
177
178.. code-block:: llvm
179
180 bb.0.entry:
181 liveins: %edi, %esi
182
183The list of live in registers and successors can be empty. The language also
184allows multiple live in register and successor lists - they are combined into
185one list by the parser.
186
187Miscellaneous Attributes
188^^^^^^^^^^^^^^^^^^^^^^^^
189
190The attributes ``IsAddressTaken``, ``IsLandingPad`` and ``Alignment`` can be
191specified 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 Lorenz8eadc3f2015-08-21 17:26:38 +0000205Machine Instructions
206--------------------
207
Alex Lorenzb981d372015-08-21 21:17:01 +0000208A machine instruction is composed of a name,
209:ref:`machine operands <machine-operands>`,
Alex Lorenz8eadc3f2015-08-21 17:26:38 +0000210:ref:`instruction flags <instruction-flags>`, and machine memory operands.
211
212The instruction's name is usually specified before the operands. The example
213below shows an instance of the X86 ``RETQ`` instruction with a single machine
214operand:
215
216.. code-block:: llvm
217
218 RETQ %eax
219
220However, if the machine instruction has one or more explicitly defined register
221operands, the instruction's name has to be specified after them. The example
222below shows an instance of the AArch64 ``LDPXpost`` instruction with three
223defined register operands:
224
225.. code-block:: llvm
226
227 %sp, %fp, %lr = LDPXpost %sp, 2
228
229The instruction names are serialized using the exact definitions from the
230target's ``*InstrInfo.td`` files, and they are case sensitive. This means that
231similar instruction names like ``TSTri`` and ``tSTRi`` represent different
232machine instructions.
233
234.. _instruction-flags:
235
236Instruction Flags
237^^^^^^^^^^^^^^^^^
238
239The 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 Lorenzb981d372015-08-21 21:17:01 +0000245.. _registers:
246
247Registers
248---------
249
250Registers are one of the key primitives in the machine instructions
251serialization language. They are primarly used in the
252:ref:`register machine operands <register-operands>`,
253but they can also be used in a number of other places, like the
254:ref:`basic block's live in list <bb-liveins>`.
255
256The physical registers are identified by their name. They use the following
257syntax:
258
259.. code-block:: llvm
260
261 %<name>
262
263The example below shows three X86 physical registers:
264
265.. code-block:: llvm
266
267 %eax
268 %r15
269 %eflags
270
271The virtual registers are identified by their ID number. They use the following
272syntax:
273
274.. code-block:: llvm
275
276 %<id>
277
278Example:
279
280.. code-block:: llvm
281
282 %0
283
284The null registers are represented using an underscore ('``_``'). They can also be
285represented using a '``%noreg``' named register, although the former syntax
286is preferred.
287
288.. _machine-operands:
289
290Machine Operands
291----------------
292
293There are seventeen different kinds of machine operands, and all of them, except
294the ``MCSymbol`` operand, can be serialized. The ``MCSymbol`` operands are
295just printed out - they can't be parsed back yet.
296
297Immediate Operands
298^^^^^^^^^^^^^^^^^^
299
300The immediate machine operands are untyped, 64-bit signed integers. The
301example below shows an instance of the X86 ``MOV32ri`` instruction that has an
302immediate 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
312Register Operands
313^^^^^^^^^^^^^^^^^
314
315The :ref:`register <registers>` primitive is used to represent the register
316machine operands. The register operands can also have optional
317:ref:`register flags <register-flags>`,
318a subregister index, and a reference to the tied register operand.
319The 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
325This example shows an instance of the X86 ``XOR32rr`` instruction that has
3265 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
334Register Flags
335~~~~~~~~~~~~~~
336
337The table below shows all of the possible register flags along with the
338corresponding 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 Lorenz3a4a60c2015-08-15 01:06:06 +0000372
Alex Lorenz3d311772015-08-06 22:55:19 +0000373.. TODO: Describe the parsers default behaviour when optional YAML attributes
374 are missing.
Alex Lorenz8eadc3f2015-08-21 17:26:38 +0000375.. TODO: Describe the syntax for the bundled instructions.
Alex Lorenzb981d372015-08-21 21:17:01 +0000376.. TODO: Describe the syntax for virtual register YAML definitions.
377.. TODO: Describe the syntax of the subregisters.
Alex Lorenz3d311772015-08-06 22:55:19 +0000378.. TODO: Describe the machine function's YAML flag attributes.
Alex Lorenz3d311772015-08-06 22:55:19 +0000379.. 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.