1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 20:23:11 +01:00
llvm-mirror/docs/GlobalISel/index.rst
Daniel Sanders 6cdb5ec3bc [globalisel][docs] Rework GMIR documentation and add an early GenericOpcode reference
Summary:
Rework the GMIR documentation to focus more on the end user than the
implementation and tie it in to the MIR document. There was also some
out-of-date information which has been removed.

The quality of the GenericOpcode reference is highly variable and drops
sharply as I worked through them all but we've got to start somewhere :-).
It would be great if others could expand on this too as there is an awful
lot to get through.

Also fix a typo in the definition of G_FLOG. Previously, the comments said
we had two base-2's (G_FLOG and G_FLOG2).

Reviewers: aemerson, volkan, rovka, arsenm

Reviewed By: rovka

Subscribers: wdng, arphaman, jfb, Petar.Avramovic, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D69545
2019-11-05 15:16:43 -08:00

106 lines
3.2 KiB
ReStructuredText

============================
Global Instruction Selection
============================
.. warning::
This document is a work in progress. It reflects the current state of the
implementation, as well as open design and implementation issues.
.. contents::
:local:
:depth: 1
Introduction
============
GlobalISel is a framework that provides a set of reusable passes and utilities
for instruction selection --- translation from LLVM IR to target-specific
Machine IR (MIR).
GlobalISel is intended to be a replacement for SelectionDAG and FastISel, to
solve three major problems:
* **Performance** --- SelectionDAG introduces a dedicated intermediate
representation, which has a compile-time cost.
GlobalISel directly operates on the post-isel representation used by the
rest of the code generator, MIR.
It does require extensions to that representation to support arbitrary
incoming IR: :ref:`gmir`.
* **Granularity** --- SelectionDAG and FastISel operate on individual basic
blocks, losing some global optimization opportunities.
GlobalISel operates on the whole function.
* **Modularity** --- SelectionDAG and FastISel are radically different and share
very little code.
GlobalISel is built in a way that enables code reuse. For instance, both the
optimized and fast selectors share the :ref:`pipeline`, and targets can
configure that pipeline to better suit their needs.
Design and Implementation Reference
===================================
More information on the design and implementation of GlobalISel can be found in
the following sections.
.. toctree::
:maxdepth: 1
GMIR
GenericOpcode
Pipeline
Porting
Resources
More information on specific passes can be found in the following sections:
.. toctree::
:maxdepth: 1
IRTranslator
Legalizer
RegBankSelect
InstructionSelect
KnownBits
.. _progress:
Progress and Future Work
========================
The initial goal is to replace FastISel on AArch64. The next step will be to
replace SelectionDAG as the optimized ISel.
``NOTE``:
While we iterate on GlobalISel, we strive to avoid affecting the performance of
SelectionDAG, FastISel, or the other MIR passes. For instance, the types of
:ref:`gmir-gvregs` are stored in a separate table in ``MachineRegisterInfo``,
that is destroyed after :ref:`instructionselect`.
.. _progress-fastisel:
FastISel Replacement
--------------------
For the initial FastISel replacement, we intend to fallback to SelectionDAG on
selection failures.
Currently, compile-time of the fast pipeline is within 1.5x of FastISel.
We're optimistic we can get to within 1.1/1.2x, but beating FastISel will be
challenging given the multi-pass approach.
Still, supporting all IR (via a complete legalizer) and avoiding the fallback
to SelectionDAG in the worst case should enable better amortized performance
than SelectionDAG+FastISel.
``NOTE``:
We considered never having a fallback to SelectionDAG, instead deciding early
whether a given function is supported by GlobalISel or not. The decision would
be based on :ref:`milegalizer` queries.
We abandoned that for two reasons:
a) on IR inputs, we'd need to basically simulate the :ref:`irtranslator`;
b) to be robust against unforeseen failures and to enable iterative
improvements.