MLIR dialects
Stay organized with collections
Save and categorize content based on your preferences.
Overview
To separate different hardware and software targets, MLIR has “dialects”,
including:
- TensorFlow IR, which represents all things possible in TensorFlow graphs.
- XLA HLO IR, which is designed to take advantage of XLA’s compilation
abilities (with output to, among other things, TPUs).
- An experimental affine dialect, which focuses on
polyhedral representations
and optimizations.
- LLVM IR, which has a 1:1 mapping between it and LLVM’s own representation,
allowing MLIR to emit GPU and CPU code through LLVM.
- TensorFlow Lite, which will translate to running code on mobile platforms.
Each dialect consists of a set of defined operations which have invariants
placed on them, like: “This is a binary operator, and the inputs and outputs
have the same types.”
Adding to MLIR
MLIR has no fixed/built-in list of globally known operations (no “intrinsics”).
Dialects can define entirely custom types, which is how MLIR can model things
like the LLVM IR type system (which has first class aggregates), domain
abstractions important for ML-optimized accelerators like quantized types, and
even the Swift or Clang type systems (which are built around Swift/Clang
declaration nodes) in the future.
If you want to connect a new low-level compiler, you would create a new dialect
and the lowerings between the TensorFlow Graph dialect and your dialect.
This smooths the path for hardware and compiler makers. You can even target
dialects at different levels in the same model; the higher-level optimizers
will respect the unfamiliar parts of the IR and wait for a lower level to handle
it.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2021-01-28 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2021-01-28 UTC."],[],[],null,["# MLIR dialects\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nTo separate different hardware and software targets, MLIR has \"dialects\",\nincluding:\n\n- TensorFlow IR, which represents all things possible in TensorFlow graphs.\n- XLA HLO IR, which is designed to take advantage of XLA's compilation abilities (with output to, among other things, TPUs).\n- An experimental affine dialect, which focuses on [polyhedral representations](https://en.wikipedia.org/wiki/Polytope_model) and optimizations.\n- LLVM IR, which has a 1:1 mapping between it and LLVM's own representation, allowing MLIR to emit GPU and CPU code through LLVM.\n- TensorFlow Lite, which will translate to running code on mobile platforms.\n\nEach dialect consists of a set of defined operations which have invariants\nplaced on them, like: \"This is a binary operator, and the inputs and outputs\nhave the same types.\"\n\nAdding to MLIR\n--------------\n\nMLIR has no fixed/built-in list of globally known operations (no \"intrinsics\").\nDialects can define entirely custom types, which is how MLIR can model things\nlike the LLVM IR type system (which has first class aggregates), domain\nabstractions important for ML-optimized accelerators like quantized types, and\neven the Swift or Clang type systems (which are built around Swift/Clang\ndeclaration nodes) in the future.\n\nIf you want to connect a new low-level compiler, you would create a new dialect\nand the lowerings between the TensorFlow Graph dialect and your dialect.\nThis smooths the path for hardware and compiler makers. You can even target\ndialects at different levels in the same model; the higher-level optimizers\nwill respect the unfamiliar parts of the IR and wait for a lower level to handle\nit."]]
