Add a doc on guidelines for contributing a new dialect to the MLIR core repo
Closes #263
PiperOrigin-RevId: 284760931
Change-Id: I7af2abb3fb8b4ad51999734cd1c95a26226675aa
diff --git a/third_party/mlir/g3doc/DeveloperGuide.md b/third_party/mlir/g3doc/DeveloperGuide.md
index a4ba9ec..7450099 100644
--- a/third_party/mlir/g3doc/DeveloperGuide.md
+++ b/third_party/mlir/g3doc/DeveloperGuide.md
@@ -51,3 +51,57 @@
## Testing guidelines
See here for the [testing guide](TestingGuide.md).
+
+## Guidelines on contributing a new dialect (or important components)
+
+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:
+
+* What is the overall goal of the dialect? What is the first implementation
+ milestone?
+* How does it fit into the MLIR dialect ecosystem?
+ * Connection: how does it connect to the existing dialects in a
+ compilation pipeline(s)?
+ * Consolidation: is there already a dialect with a similar goal or
+ matching abstractions; if so, can it be improved instead of adding a new
+ one?
+ * Reuse: how does it generalize to similar but slightly different
+ use-cases?
+* What is the community of users that it is serving?
+* Who are the future contributors/maintainers beyond those who propose the
+ dialect?
+
+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:
+
+* Edge dialects that model a representation external to MLIR. Examples include
+ LLVM, SPIR-V dialects, TensorFlow, XLA/HLO, ... Such dialects may be a
+ better fit for the project that contains the original representation instead
+ of being added to the MLIR repository. In particular, because MLIR will not
+ take an external dependency on another project.
+* Structured Abstraction dialects that generalize common features of several
+ other dialects or introduce a programming model. Generalization is sometimes
+ demonstrated by having several dialects lower to or originate from a new
+ dialect. While additional abstractions may be useful, they should be traded
+ off against the additional complexity of the dialect ecosystem. Examples of
+ abstraction dialects include the GPU and Loop dialects.
+* Transformation dialects that serve as input/output for program
+ transformations. These dialects are commonly introduced to materialize
+ transformation pre- and post-conditions in the IR, while conditions can be
+ obtained through analysis or through operation semantics. Examples include
+ Affine and Linalg 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.
