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
| .. _pipeline:
Core Pipeline
=============
There are four required passes, regardless of the optimization mode:
.. toctree::
:maxdepth: 1
IRTranslator
Legalizer
RegBankSelect
InstructionSelect
Additional passes can then be inserted at higher optimization levels or for
specific targets. For example, to match the current SelectionDAG set of
transformations: MachineCSE and a better MachineCombiner between every pass.
``NOTE``:
In theory, not all passes are always necessary.
As an additional compile-time optimization, we could skip some of the passes by
setting the relevant MachineFunction properties. For instance, if the
IRTranslator did not encounter any illegal instruction, it would set the
``legalized`` property to avoid running the :ref:`milegalizer`.
Similarly, we considered specializing the IRTranslator per-target to directly
emit target-specific MI.
However, we instead decided to keep the core pipeline simple, and focus on
minimizing the overhead of the passes in the no-op cases.
.. _maintainability-verifier:
MachineVerifier
---------------
The pass approach lets us use the ``MachineVerifier`` to enforce invariants.
For instance, a ``regBankSelected`` function may not have gvregs without
a bank.
``TODO``:
The ``MachineVerifier`` being monolithic, some of the checks we want to do
can't be integrated to it: GlobalISel is a separate library, so we can't
directly reference it from CodeGen. For instance, legality checks are
currently done in RegBankSelect/InstructionSelect proper. We could #ifdef out
the checks, or we could add some sort of verifier API.
.. _maintainability:
Maintainability
===============
.. _maintainability-iterative:
Iterative Transformations
-------------------------
Passes are split into small, iterative transformations, with all state
represented in the MIR.
This differs from SelectionDAG (in particular, the legalizer) using various
in-memory side-tables.
.. _maintainability-mir:
MIR Serialization
-----------------
.. FIXME: Update the MIRLangRef to include GMI additions.
:ref:`gmir` is serializable (see :doc:`../MIRLangRef`).
Combined with :ref:`maintainability-iterative`, this enables much finer-grained
testing, rather than requiring large and fragile IR-to-assembly tests.
The current "stage" in the :ref:`pipeline` is represented by a set of
``MachineFunctionProperties``:
* ``legalized``
* ``regBankSelected``
* ``selected``
|