llvm.org GIT mirror llvm / testing docs / MIRLangRef.rst
testing

Tree @testing (Download .tar.gz)

MIRLangRef.rst @testing

32dcc28
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
0f92e21
 
 
 
 
 
1130138
0f92e21
1130138
0f92e21
 
 
 
 
1130138
 
 
 
0f92e21
1130138
 
 
 
 
0f92e21
1130138
0f92e21
 
 
 
 
 
1130138
0f92e21
 
1130138
 
 
0f92e21
dc1a361
 
 
 
 
 
0cb25a2
 
dc1a361
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
0f92e21
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
32dcc28
 
 
1fd5773
 
32dcc28
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
32dcc28
 
 
 
 
 
1dde2af
 
 
 
 
 
 
 
32dcc28
 
 
 
 
 
 
 
1dde2af
 
32dcc28
bd978a4
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
bd978a4
 
 
 
 
 
 
 
 
88ea57f
bd978a4
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
bd978a4
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
bd978a4
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
bd978a4
 
 
 
5e825f6
 
bd978a4
 
 
 
 
 
88ea57f
bd978a4
 
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
bd978a4
 
 
 
 
 
 
 
 
 
 
ded00c7
 
 
5e825f6
 
ded00c7
 
 
 
 
 
88ea57f
ded00c7
 
 
 
 
 
 
 
88ea57f
ded00c7
 
 
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
ded00c7
 
 
5e825f6
 
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
5e825f6
 
 
 
 
88ea57f
5e825f6
 
 
 
 
 
 
 
88ea57f
5e825f6
 
 
 
 
88ea57f
5e825f6
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
88ea57f
5e825f6
 
 
 
 
 
 
 
 
 
 
 
 
0aeea88
 
5e825f6
 
88ea57f
5e825f6
 
 
 
 
 
88ea57f
5e825f6
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
bd978a4
0aeea88
 
 
 
 
 
 
 
 
 
88ea57f
0aeea88
 
 
 
 
 
1fd5773
 
 
 
 
 
 
 
88ea57f
1fd5773
 
 
 
 
 
 
 
 
 
32dcc28
 
ded00c7
5e825f6
32dcc28
1fd5773
32dcc28
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
========================================
Machine IR (MIR) Format Reference Manual
========================================

.. contents::
   :local:

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

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
<http://www.yaml.org/spec/1.2/spec.html#Introduction>`_.

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.

.. _YAML documents: http://www.yaml.org/spec/1.2/spec.html#id2800132

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 > 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 are only printed, they can't be parsed.

- A lot of the state in ``MachineModuleInfo`` isn'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 certain ``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:

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:

.. code-block:: llvm

       define i32 @inc(i32* %x) {
       entry:
         %0 = load i32, i32* %x
         %1 = add i32 %0, 1
         store i32 %1, i32* %x
         ret i32 %1
       }

.. _YAML block literal string: http://www.yaml.org/spec/1.2/spec.html#id2795688

Machine Functions
-----------------

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

.. code-block:: text

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

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:

.. code-block:: text

    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:

.. code-block:: text

    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:

.. code-block:: text

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

Examples:

.. code-block:: llvm

    %bb.0
    %bb.1.then

Successors
^^^^^^^^^^

The machine basic block's successors have to be specified before any of the
instructions:

.. code-block:: text

    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:

.. code-block:: text

    bb.0.entry:
      successors: %bb.1.then(32), %bb.2.else(16)

.. _bb-liveins:

Live In Registers
^^^^^^^^^^^^^^^^^

The machine basic block's live in registers have to be specified before any of
the instructions:

.. code-block:: text

    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`` and ``Alignment`` can be
specified in brackets after the block's definition:

.. code-block:: text

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

.. TODO: Describe the way the reference to an unnamed LLVM IR block can be
   preserved.

Machine 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:

.. code-block:: text

    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:

.. code-block:: text

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

.. _instruction-flags:

Instruction Flags
^^^^^^^^^^^^^^^^^

The flag ``frame-setup`` can be specified before the instruction's name:

.. code-block:: text

    %fp = frame-setup ADDXri %sp, 0, 0

.. _registers:

Registers
---------

Registers are one of the key primitives in the machine instructions
serialization language. They are primarly 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. They use the following
syntax:

.. code-block:: text

    %<name>

The example below shows three X86 physical registers:

.. code-block:: text

    %eax
    %r15
    %eflags

The virtual registers are identified by their ID number. They use the following
syntax:

.. code-block:: text

    %<id>

Example:

.. code-block:: text

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

.. _machine-operands:

Machine Operands
----------------

There are seventeen different kinds of machine operands, and all of them, except
the ``MCSymbol`` operand, can be serialized. The ``MCSymbol`` operands are
just printed out - they can't be parsed back yet.

Immediate Operands
^^^^^^^^^^^^^^^^^^

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``:

.. code-block:: text

    %eax = MOV32ri -42

.. TODO: Describe the CIMM (Rare) and FPIMM immediate operands.

.. _register-operands:

Register Operands
^^^^^^^^^^^^^^^^^

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:

.. code-block:: text

    [<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:

.. code-block:: text

  dead %eax = XOR32rr undef %eax, undef %eax, implicit-def dead %eflags, implicit-def %al

.. _register-flags:

Register Flags
~~~~~~~~~~~~~~

The table below shows all of the possible register flags along with the
corresponding internal ``llvm::RegState`` representation:

.. list-table::
   :header-rows: 1

   * - 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``

.. _subregister-indices:

Subregister Indices
~~~~~~~~~~~~~~~~~~~

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:

.. code-block:: text

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

Global Value Operands
^^^^^^^^^^^^^^^^^^^^^

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``:

.. code-block:: text

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

.. TODO: Describe the parsers default behaviour when optional YAML attributes
   are missing.
.. TODO: Describe the syntax for the bundled instructions.
.. TODO: Describe the syntax for virtual register YAML definitions.
.. TODO: Describe the machine function's YAML flag attributes.
.. TODO: Describe the syntax for the external symbol and register
   mask machine operands.
.. TODO: Describe the frame information YAML mapping.
.. TODO: Describe the syntax of the stack object machine operands and their
   YAML definitions.
.. TODO: Describe the syntax of the constant pool machine operands and their
   YAML definitions.
.. TODO: Describe the syntax of the jump table machine operands and their
   YAML definitions.
.. TODO: Describe the syntax of the block address machine operands.
.. TODO: Describe the syntax of the CFI index machine operands.
.. TODO: Describe the syntax of the metadata machine operands, and the
   instructions debug location attribute.
.. TODO: Describe the syntax of the target index machine operands.
.. TODO: Describe the syntax of the register live out machine operands.
.. TODO: Describe the syntax of the machine memory operands.