22 At the most fundamental level, defining a dialect in MLIR is as simple as
29 C++ code, significantly reduces maintainence burden when changing aspects of dialect
39 and other sub-components of the dialect to establish a proper layering between
40 the various different dialect components. It also prevents situations where you may
46 // our dialect. 
49 // Here is a simple definition of a dialect.
51   let summary = "A short one line description of my dialect.";
53     My dialect is a very important dialect. This section contains a much more
58   /// This is the namespace of the dialect. It is used to encapsulate the sub-components
59   /// of the dialect, such as operations ("my_dialect.foo").
62   /// The C++ namespace that the dialect, and its sub-components, get placed in.
67 The above showcases a very simple description of a dialect, but dialects have lots
72 Every dialect must implement an initialization hook to add attributes, operations, types,
74 dialect that should happen on construction. This hook is declared for every dialect to
86 for the dialect. The `summary` field expects a simple single-line string, with the
88 used to generate markdown documentation for the dialect and is used by upstream
94 dialect definition, but with any `_` characters stripped out. This means that if you name
95 your dialect `Foo_Dialect`, the generated C++ class would be `FooDialect`. In the example
96 above, we would get a C++ dialect named `MyDialect`.
100 The namespace that the C++ class for our dialect, and all of its sub-components, is placed
101 under is specified by the `cppNamespace` field. By default, uses the name of the dialect as
106 Note that this works in conjunction with the dialect's C++ code. Depending on how the generated fil…
116 attributes or types, etc. When a dialect has a dependency on another, i.e. when it constructs and/or
117 generally relies on the components of another dialect, a dialect dependency should be explicitly
119 dialect. Dialect dependencies can be recorded using the `dependentDialects` dialects field:
123   // Here we register the Arithmetic and Func dialect as dependencies of our `MyDialect`.
145 a `Type`. This is generally used when an operation within this dialect has been folded,
147 materialization, and the `materializeConstant` hook is declared on the dialect. This
171 when the dialect has some special logic to be run in the `~MyDialect`. In this case,
178 by the dialect whose name prefixes that of the attribute. For example, if an
179 operation has an attribute named `gpu.contained_module`, the `gpu` dialect
182 by our dialect, several hooks on the Dialect may be used:
186 This field generates the hook for verifying when a discardable attribute of this dialect
191 /// dialect, that was used in `op`s dictionary.
197 This field generates the hook for verifying when a discardable attribute of this dialect
203 In these cases, those operations will invoke this hook on the dialect to ensure the attribute
204 is verified. The hook necessary for the dialect to implement has the form:
208 /// dialect, that was used on the attribute dictionary of a region entry block argument.
217 This field generates the hook for verifying when a discardable attribute of this dialect
223 dialect to ensure the attribute is verified. The hook necessary for the dialect to implement
228 /// of this dialect, that was used on the attribute dictionary of a region result.
240 interface, the query will fallback to the dialect itself. The `hasOperationInterfaceFallback`
250 [interface documentation](Interfaces.md#dialect-fallback-for-opinterface).
254 When a dialect registers an Attribute or Type, it must also override the respective
256 `Dialect::parseType`/`Dialect::printType` methods. In these cases, the dialect must
258 the dialect. If all of the attributes and types of the dialect provide a mnemonic,
261 these fields are set to `1`(enabled), meaning that if a dialect needs to explicitly handle the
267 operations within a dialect. There are some cases, however, that prompt canonicalization
268 patterns to be added to the dialect-level. For example, if a dialect defines a canonicalization
272 the `getCanonicalizationPatterns` method on the dialect, which has the form:
275 /// Return the canonicalization patterns for this dialect:
335 ## Defining an Extensible dialect
342 ### Defining an extensible dialect  argument
347 class contains the necessary fields and methods to extend the dialect at
370 if (auto extensibleDialect = llvm::dyn_cast<ExtensibleDialect>(dialect)) {
379 functions. An operation defined at runtime must provide a name, a dialect in
384 // The operation name, without the dialect name prefix.
387 // The dialect defining the operation.
388 Dialect* dialect = ctx->getOrLoadDialect<MyDialect>();
426     DynamicOpDefinition::get(name, dialect, std::move(verifyFn),
469 functions. A type definition requires a name, the dialect that will register the
475 // The type name, without the dialect name prefix.
478 // The dialect defining the type.
479 Dialect* dialect = ctx->getOrLoadDialect<MyDialect>();
500     DynamicTypeDefinition::get(std::move(name), std::move(dialect),
506 generated with the format `!dialect.typename<arg1, arg2, ..., argN>`.
511 dialect->registerDynamicType(std::move(typeDef));
514 ### Parsing types defined at runtime in an extensible dialect  argument
568 functions. An attribute definition requires a name, the dialect that will
574 // The attribute name, without the dialect name prefix.
577 // The dialect defining the attribute.
578 Dialect* dialect = ctx->getOrLoadDialect<MyDialect>();
599     DynamicAttrDefinition::get(std::move(name), std::move(dialect),
605 generated with the format `!dialect.attrname<arg1, arg2, ..., argN>`.
610 dialect->registerDynamicAttr(std::move(typeDef));
613 ### Parsing attributes defined at runtime in an extensible dialect  argument
661 #### Extensible dialect