1.. _gmir: 2 3Generic Machine IR 4================== 5 6.. contents:: 7 :local: 8 9Generic MIR (gMIR) is an intermediate representation that shares the same data 10structures as :doc:`MachineIR (MIR) <../MIRLangRef>` but has more relaxed 11constraints. As the compilation pipeline proceeds, these constraints are 12gradually tightened until gMIR has become MIR. 13 14The rest of this document will assume that you are familiar with the concepts 15in :doc:`MachineIR (MIR) <../MIRLangRef>` and will highlight the differences 16between MIR and gMIR. 17 18.. _gmir-instructions: 19 20Generic Machine Instructions 21---------------------------- 22 23.. note:: 24 25 This section expands on :ref:`mir-instructions` from the MIR Language 26 Reference. 27 28Whereas MIR deals largely in Target Instructions and only has a small set of 29target independent opcodes such as ``COPY``, ``PHI``, and ``REG_SEQUENCE``, 30gMIR defines a rich collection of ``Generic Opcodes`` which are target 31independent and describe operations which are typically supported by targets. 32One example is ``G_ADD`` which is the generic opcode for an integer addition. 33More information on each of the generic opcodes can be found at 34:doc:`GenericOpcode`. 35 36The ``MachineIRBuilder`` class wraps the ``MachineInstrBuilder`` and provides 37a convenient way to create these generic instructions. 38 39.. _gmir-gvregs: 40 41Generic Virtual Registers 42------------------------- 43 44.. note:: 45 46 This section expands on :ref:`mir-registers` from the MIR Language 47 Reference. 48 49Generic virtual registers are like virtual registers but they are not assigned a 50Register Class constraint. Instead, generic virtual registers have less strict 51constraints starting with a :ref:`gmir-llt` and then further constrained to a 52:ref:`gmir-regbank`. Eventually they will be constrained to a register class 53at which point they become normal virtual registers. 54 55Generic virtual registers can be used with all the virtual register API's 56provided by ``MachineRegisterInfo``. In particular, the def-use chain API's can 57be used without needing to distinguish them from non-generic virtual registers. 58 59For simplicity, most generic instructions only accept virtual registers (both 60generic and non-generic). There are some exceptions to this but in general: 61 62* instead of immediates, they use a generic virtual register defined by an 63 instruction that materializes the immediate value (see 64 :ref:`irtranslator-constants`). Typically this is a G_CONSTANT or a 65 G_FCONSTANT. One example of an exception to this rule is G_SEXT_INREG where 66 having an immediate is mandatory. 67* instead of physical register, they use a generic virtual register that is 68 either defined by a ``COPY`` from the physical register or used by a ``COPY`` 69 that defines the physical register. 70 71.. admonition:: Historical Note 72 73 We started with an alternative representation, where MRI tracks a size for 74 each generic virtual register, and instructions have lists of types. 75 That had two flaws: the type and size are redundant, and there was no generic 76 way of getting a given operand's type (as there was no 1:1 mapping between 77 instruction types and operands). 78 We considered putting the type in some variant of MCInstrDesc instead: 79 See `PR26576 <https://llvm.org/PR26576>`_: [GlobalISel] Generic MachineInstrs 80 need a type but this increases the memory footprint of the related objects 81 82.. _gmir-regbank: 83 84Register Bank 85------------- 86 87A Register Bank is a set of register classes defined by the target. This 88definition is rather loose so let's talk about what they can achieve. 89 90Suppose we have a processor that has two register files, A and B. These are 91equal in every way and support the same instructions for the same cost. They're 92just physically stored apart and each instruction can only access registers from 93A or B but never a mix of the two. If we want to perform an operation on data 94that's in split between the two register files, we must first copy all the data 95into a single register file. 96 97Given a processor like this, we would benefit from clustering related data 98together into one register file so that we minimize the cost of copying data 99back and forth to satisfy the (possibly conflicting) requirements of all the 100instructions. Register Banks are a means to constrain the register allocator to 101use a particular register file for a virtual register. 102 103In practice, register files A and B are rarely equal. They can typically store 104the same data but there's usually some restrictions on what operations you can 105do on each register file. A fairly common pattern is for one of them to be 106accessible to integer operations and the other accessible to floating point 107operations. To accommodate this, let's rename A and B to GPR (general purpose 108registers) and FPR (floating point registers). 109 110We now have some additional constraints that limit us. An operation like G_FMUL 111has to happen in FPR and G_ADD has to happen in GPR. However, even though this 112prescribes a lot of the assignments we still have some freedom. A G_LOAD can 113happen in both GPR and FPR, and which we want depends on who is going to consume 114the loaded data. Similarly, G_FNEG can happen in both GPR and FPR. If we assign 115it to FPR, then we'll use floating point negation. However, if we assign it to 116GPR then we can equivalently G_XOR the sign bit with 1 to invert it. 117 118In summary, Register Banks are a means of disambiguating between seemingly 119equivalent choices based on some analysis of the differences when each choice 120is applied in a given context. 121 122To give some concrete examples: 123 124AArch64 125 126 AArch64 has three main banks. GPR for integer operations, FPR for floating 127 point and also for the NEON vector instruction set. The third is CCR and 128 describes the condition code register used for predication. 129 130MIPS 131 132 MIPS has five main banks of which many programs only really use one or two. 133 GPR is the general purpose bank for integer operations. FGR or CP1 is for 134 the floating point operations as well as the MSA vector instructions and a 135 few other application specific extensions. CP0 is for system registers and 136 few programs will use it. CP2 and CP3 are for any application specific 137 coprocessors that may be present in the chip. Arguably, there is also a sixth 138 for the LO and HI registers but these are only used for the result of a few 139 operations and it's of questionable value to model distinctly from GPR. 140 141X86 142 143 X86 can be seen as having 3 main banks: general-purpose, x87, and 144 vector (which could be further split into a bank per domain for single vs 145 double precision instructions). It also looks like there's arguably a few 146 more potential banks such as one for the AVX512 Mask Registers. 147 148Register banks are described by a target-provided API, 149:ref:`RegisterBankInfo <api-registerbankinfo>`. 150 151.. _gmir-llt: 152 153Low Level Type 154-------------- 155 156Additionally, every generic virtual register has a type, represented by an 157instance of the ``LLT`` class. 158 159Like ``EVT``/``MVT``/``Type``, it has no distinction between unsigned and signed 160integer types. Furthermore, it also has no distinction between integer and 161floating-point types: it mainly conveys absolutely necessary information, such 162as size and number of vector lanes: 163 164* ``sN`` for scalars 165* ``pN`` for pointers 166* ``<N x sM>`` for vectors 167 168``LLT`` is intended to replace the usage of ``EVT`` in SelectionDAG. 169 170Here are some LLT examples and their ``EVT`` and ``Type`` equivalents: 171 172 ============= ========= ====================================== 173 LLT EVT IR Type 174 ============= ========= ====================================== 175 ``s1`` ``i1`` ``i1`` 176 ``s8`` ``i8`` ``i8`` 177 ``s32`` ``i32`` ``i32`` 178 ``s32`` ``f32`` ``float`` 179 ``s17`` ``i17`` ``i17`` 180 ``s16`` N/A ``{i8, i8}`` [#abi-dependent]_ 181 ``s32`` N/A ``[4 x i8]`` [#abi-dependent]_ 182 ``p0`` ``iPTR`` ``i8*``, ``i32*``, ``%opaque*`` 183 ``p2`` ``iPTR`` ``i8 addrspace(2)*`` 184 ``<4 x s32>`` ``v4f32`` ``<4 x float>`` 185 ``s64`` ``v1f64`` ``<1 x double>`` 186 ``<3 x s32>`` ``v3i32`` ``<3 x i32>`` 187 ============= ========= ====================================== 188 189 190Rationale: instructions already encode a specific interpretation of types 191(e.g., ``add`` vs. ``fadd``, or ``sdiv`` vs. ``udiv``). Also encoding that 192information in the type system requires introducing bitcast with no real 193advantage for the selector. 194 195Pointer types are distinguished by address space. This matches IR, as opposed 196to SelectionDAG where address space is an attribute on operations. 197This representation better supports pointers having different sizes depending 198on their addressspace. 199 200.. note:: 201 202 .. caution:: 203 204 Is this still true? I thought we'd removed the 1-element vector concept. 205 Hypothetically, it could be distinct from a scalar but I think we failed to 206 find a real occurrence. 207 208 Currently, LLT requires at least 2 elements in vectors, but some targets have 209 the concept of a '1-element vector'. Representing them as their underlying 210 scalar type is a nice simplification. 211 212.. rubric:: Footnotes 213 214.. [#abi-dependent] This mapping is ABI dependent. Here we've assumed no additional padding is required. 215 216Generic Opcode Reference 217------------------------ 218 219The Generic Opcodes that are available are described at :doc:`GenericOpcode`. 220