This document attempts to describe a few developer policies used in MLIR (such as coding standards used) as well as development approach (such as, testing methods).
MLIR follows the LLVM style guide. We also adhere to the following (which deviate from or are not specified in the LLVM style guide):
git
conventions for writing a commit message, in particular the first line is the “title”, it should be followed by an empty line and an optional description. This post give examples and more details.Please run clang-format on the files you modified with the .clang-format
configuration file available in the root directory. Check the clang-format documentation for more details on integrating it with your development environment. In particular, if clang is installed system-wide, running git clang-format origin/master
will update the files in the working directory with the relevant formatting changes; don't forget to include those to the commit.
To avoid collision between options provided by different dialects, the naming convention is to prepend the dialect name to every dialect-specific passes and options in general. Options that are specific to a pass should also be prefixed with the pass name. For example, the affine dialect provides a loop tiling pass that is registered on the command line as -affine-tile
, and with a tile size option that can be set with -affine-tile-size
.
We also avoid cl::opt
to provide pass options in favor of the pass options mechanism. This allows for these options to be serialized in a pass pipeline description, as well as passing different options to multiple instances of a pass in the same pipeline.
See here for the testing guide.
To contribute a dialect (or a major component in MLIR), it is usual to write an overview “RFC” (it can be just a few informal paragraphs) and send it to the MLIR mailing list. When accepting a new component to MLIR, the community is also accepting the burden of maintaining it. The following points should be considered when evaluating whether a dialect is a good fit for the core MLIR repository:
On a practical aspect, we will expect the code to follow the other sections of this document, with an emphasis on the documentation alongside the source code.
It is prefered to upstream your dialects/components in small incremental patches that can be individually reviewed. That is, after the initial RFC has been agreed on, we encourage dialects to be built progressively by faster iterations in-tree; as long as it is clear they evolve towards their milestones and goals.
We have seen the following broad categories of dialects:
While it can be useful to frame the goals of a proposal, this categorization is not exhaustive or absolute, and the community is open to discussing any new dialect beyond this taxonomy.