llvm.org GIT mirror llvm / bbf0c3a
[docs] Add initial Global ISel documentation. This reflects the current state of Global ISel. As progress is made, we'll document our design decisions in it. Comments very welcome! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286002 91177308-0d34-0410-b5e6-96231b3b80d8 Ahmed Bougacha 2 years ago
2 changed file(s) with 676 addition(s) and 0 deletion(s). Raw diff Collapse all Expand all
0 ============================
1 Global Instruction Selection
2 ============================
3
4 .. contents::
5 :local:
6 :depth: 1
7
8 .. warning::
9 This document is a work in progress. It reflects the current state of the
10 implementation, as well as open design and implementation issues.
11
12 Introduction
13 ============
14
15 GlobalISel is a framework that provides a set of reusable passes and utilities
16 for instruction selection --- translation from LLVM IR to target-specific
17 Machine IR (MIR).
18
19 GlobalISel is intended to be a replacement for SelectionDAG and FastISel, to
20 solve three major problems:
21
22 * **Performance** --- SelectionDAG introduces a dedicated intermediate
23 representation, which has a compile-time cost.
24
25 GlobalISel directly operates on the post-isel representation used by the
26 rest of the code generator, MIR.
27 It does require extensions to that representation to support arbitrary
28 incoming IR: :ref:`gmir`.
29
30 * **Granularity** --- SelectionDAG and FastISel operate on individual basic
31 blocks, losing some global optimization opportunities.
32
33 GlobalISel operates on the whole function.
34
35 * **Modularity** --- SelectionDAG and FastISel are radically different and share
36 very little code.
37
38 GlobalISel is built in a way that enables code reuse. For instance, both the
39 optimized and fast selectors share the :ref:`pipeline`, and targets can
40 configure that pipeline to better suit their needs.
41
42
43 .. _gmir:
44
45 Generic Machine IR
46 ==================
47
48 Machine IR operates on physical registers, register classes, and (mostly)
49 target-specific instructions.
50
51 To bridge the gap with LLVM IR, GlobalISel introduces "generic" extensions to
52 Machine IR:
53
54 .. contents::
55 :local:
56
57 ``NOTE``:
58 The generic MIR (GMIR) representation still contains references to IR
59 constructs (such as ``GlobalValue``). Removing those should let us write more
60 accurate tests, or delete IR after building the initial MIR. However, it is
61 not part of the GlobalISel effort.
62
63 .. _gmir-instructions:
64
65 Generic Instructions
66 --------------------
67
68 The main addition is support for pre-isel generic machine instructions (e.g.,
69 ``G_ADD``). Like other target-independent instructions (e.g., ``COPY`` or
70 ``PHI``), these are available on all targets.
71
72 ``TODO``:
73 While we're progressively adding instructions, one kind in particular exposes
74 interesting problems: compares and how to represent condition codes.
75 Some targets (x86, ARM) have generic comparisons setting multiple flags,
76 which are then used by predicated variants.
77 Others (IR) specify the predicate in the comparison and users just get a single
78 bit. SelectionDAG uses SETCC/CONDBR vs BR_CC (and similar for select) to
79 represent this.
80
81 The ``MachineIRBuilder`` class wraps the ``MachineInstrBuilder`` and provides
82 a convenient way to create these generic instructions.
83
84 .. _gmir-gvregs:
85
86 Generic Virtual Registers
87 -------------------------
88
89 Generic instructions operate on a new kind of register: "generic" virtual
90 registers. As opposed to non-generic vregs, they are not assigned a Register
91 Class. Instead, generic vregs have a :ref:`gmir-llt`, and can be assigned
92 a :ref:`gmir-regbank`.
93
94 ``MachineRegisterInfo`` tracks the same information that it does for
95 non-generic vregs (e.g., use-def chains). Additionally, it also tracks the
96 :ref:`gmir-llt` of the register, and, instead of the ``TargetRegisterClass``,
97 its :ref:`gmir-regbank`, if any.
98
99 For simplicity, most generic instructions only accept generic vregs:
100
101 * instead of immediates, they use a gvreg defined by an instruction
102 materializing the immediate value (see :ref:`irtranslator-constants`).
103 * instead of physical register, they use a gvreg defined by a ``COPY``.
104
105 ``NOTE``:
106 We started with an alternative representation, where MRI tracks a size for
107 each gvreg, and instructions have lists of types.
108 That had two flaws: the type and size are redundant, and there was no generic
109 way of getting a given operand's type (as there was no 1:1 mapping between
110 instruction types and operands).
111 We considered putting the type in some variant of MCInstrDesc instead:
112 See `PR26576 `_: [GlobalISel] Generic MachineInstrs
113 need a type but this increases the memory footprint of the related objects
114
115 .. _gmir-regbank:
116
117 Register Bank
118 -------------
119
120 A Register Bank is a set of register classes defined by the target.
121 A bank has a size, which is the maximum store size of all covered classes.
122
123 In general, cross-class copies inside a bank are expected to be cheaper than
124 copies across banks. They are also coalesceable by the register coalescer,
125 whereas cross-bank copies are not.
126
127 Also, equivalent operations can be performed on different banks using different
128 instructions.
129
130 For example, X86 can be seen as having 3 main banks: general-purpose, x87, and
131 vector (which could be further split into a bank per domain for single vs
132 double precision instructions).
133
134 Register banks are described by a target-provided API,
135 :ref:`RegisterBankInfo `.
136
137 .. _gmir-llt:
138
139 Low Level Type
140 --------------
141
142 Additionally, every generic virtual register has a type, represented by an
143 instance of the ``LLT`` class.
144
145 Like ``EVT``/``MVT``/``Type``, it has no distinction between unsigned and signed
146 integer types. Furthermore, it also has no distinction between integer and
147 floating-point types: it mainly conveys absolutely necessary information, such
148 as size and number of vector lanes:
149
150 * ``sN`` for scalars
151 * ``pN`` for pointers
152 * ```` for vectors
153 * ``unsized`` for labels, etc..
154
155 ``LLT`` is intended to replace the usage of ``EVT`` in SelectionDAG.
156
157 Here are some LLT examples and their ``EVT`` and ``Type`` equivalents:
158
159 ============= ========= ======================================
160 LLT EVT IR Type
161 ============= ========= ======================================
162 ``s1`` ``i1`` ``i1``
163 ``s8`` ``i8`` ``i8``
164 ``s32`` ``i32`` ``i32``
165 ``s32`` ``f32`` ``float``
166 ``s17`` ``i17`` ``i17``
167 ``s16`` N/A ``{i8, i8}``
168 ``s32`` N/A ``[4 x i8]``
169 ``p0`` ``iPTR`` ``i8*``, ``i32*``, ``%opaque*``
170 ``p2`` ``iPTR`` ``i8 addrspace(2)*``
171 ``<4 x s32>`` ``v4f32`` ``<4 x float>``
172 ``s64`` ``v1f64`` ``<1 x double>``
173 ``<3 x s32>`` ``v3i32`` ``<3 x i32>``
174 ``unsized`` ``Other`` ``label``
175 ============= ========= ======================================
176
177
178 Rationale: instructions already encode a specific interpretation of types
179 (e.g., ``add`` vs. ``fadd``, or ``sdiv`` vs. ``udiv``). Also encoding that
180 information in the type system requires introducing bitcast with no real
181 advantage for the selector.
182
183 Pointer types are distinguished by address space. This matches IR, as opposed
184 to SelectionDAG where address space is an attribute on operations.
185 This representation better supports pointers having different sizes depending
186 on their addressspace.
187
188 ``NOTE``:
189 Currently, LLT requires at least 2 elements in vectors, but some targets have
190 the concept of a '1-element vector'. Representing them as their underlying
191 scalar type is a nice simplification.
192
193 ``TODO``:
194 Currently, non-generic virtual registers, defined by non-pre-isel-generic
195 instructions, cannot have a type, and thus cannot be used by a pre-isel generic
196 instruction. Instead, they are given a type using a COPY. We could relax that
197 and allow types on all vregs: this would reduce the number of MI required when
198 emitting target-specific MIR early in the pipeline. This should purely be
199 a compile-time optimization.
200
201 .. _pipeline:
202
203 Core Pipeline
204 =============
205
206 There are four required passes, regardless of the optimization mode:
207
208 .. contents::
209 :local:
210
211 Additional passes can then be inserted at higher optimization levels or for
212 specific targets. For example, to match the current SelectionDAG set of
213 transformations: MachineCSE and a better MachineCombiner between every pass.
214
215 ``NOTE``:
216 In theory, not all passes are always necessary.
217 As an additional compile-time optimization, we could skip some of the passes by
218 setting the relevant MachineFunction properties. For instance, if the
219 IRTranslator did not encounter any illegal instruction, it would set the
220 ``legalized`` property to avoid running the :ref:`milegalizer`.
221 Similarly, we considered specializing the IRTranslator per-target to directly
222 emit target-specific MI.
223 However, we instead decided to keep the core pipeline simple, and focus on
224 minimizing the overhead of the passes in the no-op cases.
225
226
227 .. _irtranslator:
228
229 IRTranslator
230 ------------
231
232 This pass translates the input LLVM IR ``Function`` to a GMIR
233 ``MachineFunction``.
234
235 ``TODO``:
236 This currently doesn't support the more complex instructions, in particular
237 those involving control flow (``switch``, ``invoke``, ...).
238 For ``switch`` in particular, we can initially use the ``LowerSwitch`` pass.
239
240 .. _api-calllowering:
241
242 API: CallLowering
243 ^^^^^^^^^^^^^^^^^
244
245 The ``IRTranslator`` (using the ``CallLowering`` target-provided utility) also
246 implements the ABI's calling convention by lowering calls, returns, and
247 arguments to the appropriate physical register usage and instruction sequences.
248
249 .. _irtranslator-aggregates:
250
251 Aggregates
252 ^^^^^^^^^^
253
254 Aggregates are lowered to a single scalar vreg.
255 This differs from SelectionDAG's multiple vregs via ``GetValueVTs``.
256
257 ``TODO``:
258 As some of the bits are undef (padding), we should consider augmenting the
259 representation with additional metadata (in effect, caching computeKnownBits
260 information on vregs).
261 See `PR26161 `_: [GlobalISel] Value to vreg during
262 IR to MachineInstr translation for aggregate type
263
264 .. _irtranslator-constants:
265
266 Constant Lowering
267 ^^^^^^^^^^^^^^^^^
268
269 The ``IRTranslator`` lowers ``Constant`` operands into uses of gvregs defined
270 by ``G_CONSTANT`` or ``G_FCONSTANT`` instructions.
271 Currently, these instructions are always emitted in the entry basic block.
272 In a ``MachineFunction``, each ``Constant`` is materialized by a single gvreg.
273
274 This is beneficial as it allows us to fold constants into immediate operands
275 during :ref:`instructionselect`, while still avoiding redundant materializations
276 for expensive non-foldable constants.
277 However, this can lead to unnecessary spills and reloads in an -O0 pipeline, as
278 these vregs can have long live ranges.
279
280 ``TODO``:
281 We're investigating better placement of these instructions, in fast and
282 optimized modes.
283
284
285 .. _milegalizer:
286
287 Legalizer
288 ---------
289
290 This pass transforms the generic machine instructions such that they are legal.
291
292 A legal instruction is defined as:
293
294 * **selectable** --- the target will later be able to select it to a
295 target-specific (non-generic) instruction.
296
297 * operating on **vregs that can be loaded and stored** -- if necessary, the
298 target can select a ``G_LOAD``/``G_STORE`` of each gvreg operand.
299
300 As opposed to SelectionDAG, there are no legalization phases. In particular,
301 'type' and 'operation' legalization are not separate.
302
303 Legalization is iterative, and all state is contained in GMIR. To maintain the
304 validity of the intermediate code, instructions are introduced:
305
306 * ``G_SEQUENCE`` --- concatenate multiple registers into a single wider
307 register.
308
309 * ``G_EXTRACT`` --- extract multiple registers (as contiguous sequences of bits)
310 from a single wider register.
311
312 As they are expected to be temporary byproducts of the legalization process,
313 they are combined at the end of the :ref:`milegalizer` pass.
314 If any remain, they are expected to always be selectable, using loads and stores
315 if necessary.
316
317 .. _api-legalizerinfo:
318
319 API: LegalizerInfo
320 ^^^^^^^^^^^^^^^^^^
321
322 Currently the API is broadly similar to SelectionDAG/TargetLowering, but
323 extended in two ways:
324
325 * The set of available actions is wider, avoiding the currently very
326 overloaded ``Expand`` (which can cover everything from libcalls to
327 scalarization depending on the node's opcode).
328
329 * Since there's no separate type legalization, independently varying
330 types on an instruction can have independent actions. For example a
331 ``G_ICMP`` has 2 independent types: the result and the inputs; we need
332 to be able to say that comparing 2 s32s is OK, but the s1 result
333 must be dealt with in another way.
334
335 As such, the primary key when deciding what to do is the ``InstrAspect``,
336 essentially a tuple consisting of ``(Opcode, TypeIdx, Type)`` and mapping to a
337 suggested course of action.
338
339 An example use might be:
340
341 .. code-block:: c++
342
343 // The CPU can't deal with an s1 result, do something about it.
344 setAction({G_ICMP, 0, s1}, WidenScalar);
345 // An s32 input (the second type) is fine though.
346 setAction({G_ICMP, 1, s32}, Legal);
347
348
349 ``TODO``:
350 An alternative worth investigating is to generalize the API to represent
351 actions using ``std::function`` that implements the action, instead of explicit
352 enum tokens (``Legal``, ``WidenScalar``, ...).
353
354 ``TODO``:
355 Moreover, we could use TableGen to initially infer legality of operation from
356 existing patterns (as any pattern we can select is by definition legal).
357 Expanding that to describe legalization actions is a much larger but
358 potentially useful project.
359
360 .. _milegalizer-scalar-narrow:
361
362 Scalar narrow types
363 ^^^^^^^^^^^^^^^^^^^
364
365 In the AArch64 port, we currently mark as legal operations on narrow integer
366 types that have a legal equivalent in a wider type.
367
368 For example, this:
369
370 %2(GPR,s8) = G_ADD %0, %1
371
372 is selected to a 32-bit instruction:
373
374 %2(GPR32) = ADDWrr %0, %1
375
376 This avoids unnecessarily legalizing operations that can be seen as legal:
377 8-bit additions are supported, but happen to have a 32-bit result with the high
378 24 bits undefined.
379
380 ``TODO``:
381 This has implications regarding vreg classes (as narrow values can now be
382 represented by wider vregs) and should be investigated further.
383
384 ``TODO``:
385 In particular, s1 comparison results can be represented as wider values in
386 different ways.
387 SelectionDAG has the notion of BooleanContents, which allows targets to choose
388 what true and false are when in a larger register:
389
390 * ``ZeroOrOne`` --- if only 0 and 1 are valid bools, even in a larger register.
391 * ``ZeroOrMinusOne`` --- if -1 is true (common for vector instructions,
392 where compares produce -1).
393 * ``Undefined`` --- if only the low bit is relevant in determining truth.
394
395 .. _milegalizer-non-power-of-2:
396
397 Non-power of 2 types
398 ^^^^^^^^^^^^^^^^^^^^
399
400 ``TODO``:
401 Types which have a size that isn't a power of 2 aren't currently supported.
402 The setAction API will probably require changes to support them.
403 Even notionally explicitly specified operations only make suggestions
404 like "Widen" or "Narrow". The eventual type is still unspecified and a
405 search is performed by repeated doubling/halving of the type's
406 size.
407 This is incorrect for types that aren't a power of 2. It's reasonable to
408 expect we could construct an efficient set of side-tables for more general
409 lookups though, encoding a map from the integers (i.e. the size of the current
410 type) to types (the legal size).
411
412 .. _milegalizer-vector:
413
414 Vector types
415 ^^^^^^^^^^^^
416
417 Vectors first get their element type legalized: ```` becomes
418 ```` such that at least one operation is legal with ``sC``.
419
420 This is currently specified by the function ``setScalarInVectorAction``, called
421 for example as:
422
423 setScalarInVectorAction(G_ICMP, s1, WidenScalar);
424
425 Next the number of elements is chosen so that the entire operation is
426 legal. This aspect is not controllable at the moment, but probably
427 should be (you could imagine disagreements on whether a ``<2 x s8>``
428 operation should be scalarized or extended to ``<8 x s8>``).
429
430
431 .. _regbankselect:
432
433 RegBankSelect
434 -------------
435
436 This pass constrains the :ref:`gmir-gvregs` operands of generic
437 instructions to some :ref:`gmir-regbank`.
438
439 It iteratively maps instructions to a set of per-operand bank assignment.
440 The possible mappings are determined by the target-provided
441 :ref:`RegisterBankInfo `.
442 The mapping is then applied, possibly introducing ``COPY`` instructions if
443 necessary.
444
445 It traverses the ``MachineFunction`` top down so that all operands are already
446 mapped when analyzing an instruction.
447
448 This pass could also remap target-specific instructions when beneficial.
449 In the future, this could replace the ExeDepsFix pass, as we can directly
450 select the best variant for an instruction that's available on multiple banks.
451
452 .. _api-registerbankinfo:
453
454 API: RegisterBankInfo
455 ^^^^^^^^^^^^^^^^^^^^^
456
457 The ``RegisterBankInfo`` class describes multiple aspects of register banks.
458
459 * **Banks**: ``addRegBankCoverage`` --- which register bank covers each
460 register class.
461
462 * **Cross-Bank Copies**: ``copyCost`` --- the cost of a ``COPY`` from one bank
463 to another.
464
465 * **Default Mapping**: ``getInstrMapping`` --- the default bank assignments for
466 a given instruction.
467
468 * **Alternative Mapping**: ``getInstrAlternativeMapping`` --- the other
469 possible bank assignments for a given instruction.
470
471 ``TODO``:
472 All this information should eventually be static and generated by TableGen,
473 mostly using existing information augmented by bank descriptions.
474
475 ``TODO``:
476 ``getInstrMapping`` is currently separate from ``getInstrAlternativeMapping``
477 because the latter is more expensive: as we move to static mapping info,
478 both methods should be free, and we should merge them.
479
480 .. _regbankselect-modes:
481
482 RegBankSelect Modes
483 ^^^^^^^^^^^^^^^^^^^
484
485 ``RegBankSelect`` currently has two modes:
486
487 * **Fast** --- For each instruction, pick a target-provided "default" bank
488 assignment. This is the default at -O0.
489
490 * **Greedy** --- For each instruction, pick the cheapest of several
491 target-provided bank assignment alternatives.
492
493 We intend to eventually introduce an additional optimizing mode:
494
495 * **Global** --- Across multiple instructions, pick the cheapest combination of
496 bank assignments.
497
498 ``NOTE``:
499 On AArch64, we are considering using the Greedy mode even at -O0 (or perhaps at
500 backend -O1): because :ref:`gmir-llt` doesn't distinguish floating point from
501 integer scalars, the default assignment for loads and stores is the integer
502 bank, introducing cross-bank copies on most floating point operations.
503
504
505 .. _instructionselect:
506
507 InstructionSelect
508 -----------------
509
510 This pass transforms generic machine instructions into equivalent
511 target-specific instructions. It traverses the ``MachineFunction`` bottom-up,
512 selecting uses before definitions, enabling trivial dead code elimination.
513
514 .. _api-instructionselector:
515
516 API: InstructionSelector
517 ^^^^^^^^^^^^^^^^^^^^^^^^
518
519 The target implements the ``InstructionSelector`` class, containing the
520 target-specific selection logic proper.
521
522 The instance is provided by the subtarget, so that it can specialize the
523 selector by subtarget feature (with, e.g., a vector selector overriding parts
524 of a general-purpose common selector).
525 We might also want to parameterize it by MachineFunction, to enable selector
526 variants based on function attributes like optsize.
527
528 The simple API consists of:
529
530 .. code-block:: c++
531
532 virtual bool select(MachineInstr &MI)
533
534 This target-provided method is responsible for mutating (or replacing) a
535 possibly-generic MI into a fully target-specific equivalent.
536 It is also responsible for doing the necessary constraining of gvregs into the
537 appropriate register classes.
538
539 The ``InstructionSelector`` can fold other instructions into the selected MI,
540 by walking the use-def chain of the vreg operands.
541 As GlobalISel is Global, this folding can occur across basic blocks.
542
543 ``TODO``:
544 Currently, the Select pass is implemented with hand-written c++, similar to
545 FastISel, rather than backed by tblgen'erated pattern-matching.
546 We intend to eventually reuse SelectionDAG patterns.
547
548
549 .. _maintainability:
550
551 Maintainability
552 ===============
553
554 .. _maintainability-iterative:
555
556 Iterative Transformations
557 -------------------------
558
559 Passes are split into small, iterative transformations, with all state
560 represented in the MIR.
561
562 This differs from SelectionDAG (in particular, the legalizer) using various
563 in-memory side-tables.
564
565
566 .. _maintainability-mir:
567
568 MIR Serialization
569 -----------------
570
571 .. FIXME: Update the MIRLangRef to include GMI additions.
572
573 :ref:`gmir` is serializable (see :doc:`MIRLangRef`).
574 Combined with :ref:`maintainability-iterative`, this enables much finer-grained
575 testing, rather than requiring large and fragile IR-to-assembly tests.
576
577 The current "stage" in the :ref:`pipeline` is represented by a set of
578 ``MachineFunctionProperties``:
579
580 * ``legalized``
581 * ``regBankSelected``
582 * ``selected``
583
584
585 .. _maintainability-verifier:
586
587 MachineVerifier
588 ---------------
589
590 The pass approach lets us use the ``MachineVerifier`` to enforce invariants.
591 For instance, a ``regBankSelected`` function may not have gvregs without
592 a bank.
593
594 ``TODO``:
595 The ``MachineVerifier`` being monolithic, some of the checks we want to do
596 can't be integrated to it: GlobalISel is a separate library, so we can't
597 directly reference it from CodeGen. For instance, legality checks are
598 currently done in RegBankSelect/InstructionSelect proper. We could #ifdef out
599 the checks, or we could add some sort of verifier API.
600
601
602 .. _progress:
603
604 Progress and Future Work
605 ========================
606
607 The initial goal is to replace FastISel on AArch64. The next step will be to
608 replace SelectionDAG as the optimized ISel.
609
610 ``NOTE``:
611 While we iterate on GlobalISel, we strive to avoid affecting the performance of
612 SelectionDAG, FastISel, or the other MIR passes. For instance, the types of
613 :ref:`gmir-gvregs` are stored in a separate table in ``MachineRegisterInfo``,
614 that is destroyed after :ref:`instructionselect`.
615
616 .. _progress-fastisel:
617
618 FastISel Replacement
619 --------------------
620
621 For the initial FastISel replacement, we intend to fallback to SelectionDAG on
622 selection failures.
623
624 Currently, compile-time of the fast pipeline is within 1.5x of FastISel.
625 We're optimistic we can get to within 1.1/1.2x, but beating FastISel will be
626 challenging given the multi-pass approach.
627 Still, supporting all IR (via a complete legalizer) and avoiding the fallback
628 to SelectionDAG in the worst case should enable better amortized performance
629 than SelectionDAG+FastISel.
630
631 ``NOTE``:
632 We considered never having a fallback to SelectionDAG, instead deciding early
633 whether a given function is supported by GlobalISel or not. The decision would
634 be based on :ref:`milegalizer` queries.
635 We abandoned that for two reasons:
636 a) on IR inputs, we'd need to basically simulate the :ref:`irtranslator`;
637 b) to be robust against unforeseen failures and to enable iterative
638 improvements.
639
640 .. _progress-targets:
641
642 Support For Other Targets
643 -------------------------
644
645 In parallel, we're investigating adding support for other - ideally quite
646 different - targets. For instance, there is some initial AMDGPU support.
647
648
649 .. _porting:
650
651 Porting GlobalISel to A New Target
652 ==================================
653
654 There are four major classes to implement by the target:
655
656 * :ref:`CallLowering ` --- lower calls, returns, and arguments
657 according to the ABI.
658 * :ref:`RegisterBankInfo ` --- describe
659 :ref:`gmir-regbank` coverage, cross-bank copy cost, and the mapping of
660 operands onto banks for each instruction.
661 * :ref:`LegalizerInfo ` --- describe what is legal, and how
662 to legalize what isn't.
663 * :ref:`InstructionSelector ` --- select generic MIR
664 to target-specific MIR.
665
666 Additionally:
667
668 * ``TargetPassConfig`` --- create the passes constituting the pipeline,
669 including additional passes not included in the :ref:`pipeline`.
670 * ``GISelAccessor`` --- setup the various subtarget-provided classes, with a
671 graceful fallback to no-op when GlobalISel isn't enabled.
271271 FaultMaps
272272 MIRLangRef
273273 Coroutines
274 GlobalISel
274275
275276 :doc:`WritingAnLLVMPass`
276277 Information on how to write LLVM transformations and analyses.
388389
389390 :doc:`Coroutines`
390391 LLVM support for coroutines.
392
393 :doc:`GlobalISel`
394 This describes the prototype instruction selection replacement, GlobalISel.
391395
392396 Development Process Documentation
393397 =================================