This glossary contains definitions of MLIR-specific terminology. It is intended to be a quick reference document. For terms which are well-documented elsewhere, definitions are kept brief and the header links to the more in-depth documentation.
A sequential list of operations without control flow.
Also called a basic block.
The transformation of code represented in one dialect into a semantically equivalent representation in another dialect (i.e. inter-dialect conversion) or the same dialect (i.e. intra-dialect conversion).
In the context of MLIR, conversion is distinct from translation. Conversion refers to a transformation between (or within) dialects, but all still within MLIR, whereas translation refers to a transformation between MLIR and an external representation.
Declarative Rewrite Rule (DRR)
A rewrite rule which can be
defined declaratively (e.g. through specification in a
TableGen record). At compiler build time,
these rules are expanded into an equivalent mlir::RewritePattern subclass.
A dialect is a grouping of functionality which can be used to extend the MLIR system.
A dialect creates a unique namespace within which new
operations, attributes, and
types are defined. This is the fundamental method by
which to extend MLIR.
In this way, MLIR is a meta-IR: its extensible framework allows it to be leveraged in many different ways (e.g. at different levels of the compilation process). Dialects provide an abstraction for the different uses of MLIR while recognizing that they are all a part of the meta-IR that is MLIR.
The tutorial provides an example of interfacing with MLIR in this way.
(Note that we have intentionally selected the term "dialect" instead of "language", as the latter would wrongly suggest that these different namespaces define entirely distinct IRs.)
To transform code represented in MLIR into a semantically equivalent representation which is external to MLIR.
The tool that performs such a transformation is called an exporter.
See also: translation.
An operation with a name containing one region.
The region of a function is not allowed to implicitly capture values defined outside of the function, and all external references must use function arguments or attributes that establish a symbolic connection.
To transform code represented in an external representation into a semantically equivalent representation in MLIR.
The tool that performs such a transformation is called an importer.
See also: translation.
The process of transforming operations into a semantically equivalent representation which adheres to the requirements set by the conversion target.
That is, legalization is accomplished if and only if the new representation contains only operations which are legal, as specified in the conversion target.
The process of transforming a higher-level representation of an operation into a lower-level, but semantically equivalent, representation.
In MLIR, this is typically accomplished through dialect conversion. This provides a framework by which to define the requirements of the lower-level representation, called the conversion target, by specifying which operations are legal versus illegal after lowering.
See also: legalization.
An operation which contains a single region containing a single block that is comprised of operations.
This provides an organizational structure for MLIR operations, and is the expected top-level operation in the IR: the textual parser returns a Module.
Operation (op)
A unit of code in MLIR. Operations are the building blocks for all code and computations represented by MLIR. They are fully extensible (there is no fixed list of operations) and have application-specific semantics.
An operation can have zero or more regions. Note that this creates a nested IR structure, as regions consist of blocks, which in turn, consist of a list of operations.
In MLIR, there are two main classes related to operations: Operation and Op.
Operation is the actual opaque instance of the operation, and represents the
general API into an operation instance. An Op is the base class of a derived
operation, like ConstantOp, and acts as smart pointer wrapper around a
Operation*
The process of converting from a source format to a target format and then back to the source format.
This is a good way of gaining confidence that the target format richly models the source format. This is particularly relevant in the MLIR context, since MLIR's multi-level nature allows for easily writing target dialects that model a source format (such as TensorFlow GraphDef or another non-MLIR format) faithfully and have a simple conversion procedure. Further cleanup/lowering can be done entirely within the MLIR representation. This separation - making the importer as simple as possible and performing all further cleanups/lowering in MLIR - has proven to be a useful design pattern.
An operation which must terminate a block. Terminator operations are a special category of operations.
An A->B->C lowering; that is, a lowering in which multiple patterns may be applied in order to fully transform an illegal operation into a set of legal ones.
This provides the flexibility that the conversion framework may perform the lowering in multiple stages of applying patterns (which may utilize intermediate patterns not in the conversion target) in order to fully legalize an operation. This is accomplished through partial conversion.
The transformation of code represented in an external (non-MLIR) representation into a semantically equivalent representation in MLIR (i.e. importing), or the inverse (i.e. exporting).
In the context of MLIR, translation is distinct from conversion. Translation refers to a transformation between MLIR and an external representation, whereas conversion refers to a transformation within MLIR (between or within dialects).