forked from OSchip/llvm-project
89 lines
4.2 KiB
Markdown
89 lines
4.2 KiB
Markdown
# Multi-Level Intermediate Representation Overview
|
||
|
||
The MLIR project aims to define a common intermediate representation (IR) that
|
||
will unify the infrastructure required to execute high performance machine
|
||
learning models in TensorFlow and similar ML frameworks. This project will
|
||
include the application of HPC techniques, along with integration of search
|
||
algorithms like reinforcement learning. This project aims to reduce the cost to
|
||
bring up new hardware, and improve usability for existing TensorFlow users.
|
||
|
||
## What is this doc?
|
||
|
||
Whereas the [MLIR draft specification](LangRef.md) discusses the details of the
|
||
IR in a dry style intended to be a long-lived reference document, this document
|
||
discusses higher level issues. This includes:
|
||
* How we see the IR being used
|
||
* How the compiler will be implemented
|
||
* What capabilities the IR enables
|
||
|
||
## More resources
|
||
|
||
For more information on MLIR, please see:
|
||
|
||
* [The MLIR draft specification](LangRef.md), which describes the IR itself,
|
||
* [The MLIR rationale document](Rationale.md), covering motivation behind some
|
||
decisions,
|
||
* previous external [talks](#talks),
|
||
|
||
or join the [MLIR mailing list](TODO).
|
||
|
||
TODO: Replace with actual mailing list.
|
||
|
||
## What is MLIR for?
|
||
|
||
MLIR is intended to be a hybrid IR which can support multiple different
|
||
requirements in a unified infrastructure. For example, this includes:
|
||
|
||
* The ability to represent all TensorFlow graphs, including dynamic shapes,
|
||
the user-extensible op ecosystem, TensorFlow variables, etc.
|
||
* Optimizations and transformations typically done on a TensorFlow graph, e.g.
|
||
in Grappler.
|
||
* Quantization and other graph transformations done on a TensorFlow graph or
|
||
the TF Lite representation.
|
||
* Representation of kernels for ML operations in a form suitable for
|
||
optimization.
|
||
* Ability to host high-performance-computing-style loop optimizations across
|
||
kernels (fusion, loop interchange, tiling, etc), and transform memory
|
||
layouts of data.
|
||
* Code generation "lowering" transformations such as DMA insertion, explicit
|
||
cache management, memory tiling, and vectorization for 1D and 2D register
|
||
architectures.
|
||
* Ability to represent target-specific operations, e.g. the MXU on TPUs.
|
||
|
||
As MLIR is a common IR which also supports hardware specific operations. Thus,
|
||
any investment into the infrastructure surrounding MLIR (e.g. the compiler
|
||
passes that work on it) should yield good returns; many targets can use that
|
||
infrastructure and will benefit from it.
|
||
|
||
MLIR is a powerful representation, but it also has non-goals. We do not try to
|
||
support low level machine code generation algorithms (like register allocation
|
||
and instruction scheduling). They are a better fit for lower level optimizers
|
||
(such as LLVM). Also, we do not intend MLIR to be a source language that
|
||
end-users would themselves write kernels in (analogous to CUDA C++). While we'd
|
||
love to see a kernel language happen someday, that will be an independent
|
||
project that compiles down to MLIR.
|
||
|
||
## Compiler Infrastructure {#compiler-infrastructure}
|
||
|
||
We benefitted from the experience gained building HLO, LLVM and SIL when
|
||
building MLIR. We will directly adopt existing best practices, e.g. writing and
|
||
maintaining an IR spec, building an IR verifier, provide the ability to dump and
|
||
parse MLIR files to text, write extensive unit tests with the
|
||
[FileCheck](https://llvm.org/docs/CommandGuide/FileCheck.html) tool, and build
|
||
the infrastructure as a set of modular libraries that can be combined in new
|
||
ways. We plan to use the infrastructure developed by the XLA team for
|
||
performance analysis and benchmarking.
|
||
|
||
Other lessons have been incorporated and integrated into the design in subtle
|
||
ways. For example, LLVM has non-obvious design mistakes that prevent a
|
||
multithreaded compiler from working on multiple functions in an LLVM module at
|
||
the same time. MLIR solves these problems by having per-function constant pools
|
||
and by making references explicit with function_ref.
|
||
|
||
# MLIR talks {#talks}
|
||
|
||
* "[MLIR Primer: A Compiler Infrastructure for the End of Moore’s Law](https://drive.google.com/file/d/1hUeAJXcAXwz82RXA5VtO5ZoH8cVQhrOK/view?usp=sharing)",
|
||
Chris Lattner & Jacques Pienaar, Google at
|
||
[Compilers for Machine Learning](https://www.c4ml.org/) workshop at
|
||
[CGO 2019](http://cgo.org/cgo2019/).
|