[mlir][docs] Group the docs for defining dialect components

[rriddle]

Summary

This moves the documentation for defining dialects, attributes/types,
and operations into a new DefiningDialects folder. This helps to
keep the documentation grouped together, making it easier to find
related documentation.

[jpienaar]

Makes sense to me, thanks!

[mehdi_amini]

You may need to check the website repo for references to update

mlir/docs/Canonicalization.md

 
 This mechanism allows for providing canonicalizations as a set of
 `RewritePattern`s, either imperatively defined in C++ or declaratively as
 [Declarative Rewrite Rules](DeclarativeRewrites.md). The pattern rewrite
 infrastructure allows for expressing many different types of canonicalizations.
 These transformations may be as simple as replacing a multiplication with a
 shift, or even replacing a conditional branch with an unconditional one.
 
-In [ODS](OpDefinitions.md), an operation can set the `hasCanonicalizer` bit or
+In [ODS](DefiningDialects/Operations.md), an operation can set the `hasCanonicalizer` bit or
 the `hasCanonicalizeMethod` bit to generate a declaration for the
 `getCanonicalizationPatterns` method:
 
 ```tablegen
 def MyOp : ... {
   // I want to define a fully general set of patterns for this op.
   let hasCanonicalizer = 1;
 }

 
 `fold` has the restriction that no new operations may be created, and only the
 root operation may be replaced (but not erased). It allows for updating an
 operation in-place, or returning a set of pre-existing values (or attributes) to
 replace the operation with. This ensures that the `fold` method is a truly
 "local" transformation, and can be invoked without the need for a pattern
 rewriter.
 
-In [ODS](OpDefinitions.md), an operation can set the `hasFolder` bit to generate
+In [ODS](DefiningDialects/Operations.md), an operation can set the `hasFolder` bit to generate
 a declaration for the `fold` method. This method takes on a different form,
 depending on the structure of the operation.
 
 ```tablegen
 def MyOp : ... {
   let hasFolder = 1;
 }
 ```

 this result is "constant". The `Attribute` is the constant representation of the
 value. Users of the `fold` method, such as the canonicalizer pass, will take
 these `Attribute`s and materialize constant operations in the IR to represent
 them. To enable this materialization, the dialect of the operation must
 implement the `materializeConstant` hook. This hook takes in an `Attribute`
 value, generally returned by `fold`, and produces a "constant-like" operation
 that materializes that value.
 
-In [ODS](DefiningDialects.md), a dialect can set the `hasConstantMaterializer` bit
+In [ODS](DefiningDialects/_index.md), a dialect can set the `hasConstantMaterializer` bit
 to generate a declaration for the `materializeConstant` method.
 
 ```tablegen
 def MyDialect : ... {
   let hasConstantMaterializer = 1;
 }
 ```
 

mlir/docs/DeclarativeRewrites.md

 # Table-driven Declarative Rewrite Rule (DRR)
 
 In addition to subclassing the `mlir::RewritePattern` C++ class, MLIR also
 supports defining rewrite rules in a declarative manner. Similar to
-[Op Definition Specification](OpDefinitions.md) (ODS), this is achieved via
+[Op Definition Specification](DefiningDialects/Operations.md) (ODS), this is achieved via
 [TableGen][TableGen], which is a language to maintain records of domain-specific
 information. The rewrite rules are specified concisely in a TableGen record,
 which will be expanded into an equivalent `mlir::RewritePattern` subclass at
 compiler build time.
 
 This manual explains in detail all of the available mechanisms for defining
 rewrite rules in such a declarative manner. It aims to be a specification
 instead of a tutorial. Please refer to
 [Quickstart tutorial to adding MLIR graph rewrite](Tutorials/QuickstartRewrites.md)
 for the latter.
 
 Given that declarative rewrite rules depend on op definition specification, this
-manual assumes knowledge of the [ODS](OpDefinitions.md) doc.
+manual assumes knowledge of the [ODS](DefiningDialects/Operations.md) doc.
 
 [TOC]
 
 ## Benefits
 
 Compared to the hand-written C++ classes, this declarative approach has several
 benefits, including but not limited to:
 

mlir/docs/DefiningDialects/AttributesAndTypes.md

 # Defining Dialect Attributes and Types
 
 This document describes how to define dialect
-[attributes](LangRef.md/#attributes) and [types](LangRef.md/#type-system).
+[attributes](../LangRef.md/#attributes) and [types](../LangRef.md/#type-system).
 
 [TOC]
 
 ## LangRef Refresher
 
 Before diving into how to define these constructs, below is a quick refresher
-from the [MLIR LangRef](LangRef.md).
+from the [MLIR LangRef](../LangRef.md).
 
 ### Attributes
 
 Attributes are the mechanism for specifying constant data on operations in
 places where a variable is never allowed - e.g. the comparison predicate of a
-[`arith.cmpi` operation](Dialects/ArithOps.md#arithcmpi-mlirarithcmpiop), or
-the underlying value of a [`arith.constant` operation](Dialects/ArithOps.md#arithconstant-mlirarithconstantop).
+[`arith.cmpi` operation](../Dialects/ArithOps.md#arithcmpi-mlirarithcmpiop), or
+the underlying value of a [`arith.constant` operation](../Dialects/ArithOps.md#arithconstant-mlirarithconstantop).
 Each operation has an attribute dictionary, which associates a set of attribute
 names to attribute values.
 
 ### Types
 
 Every SSA value, such as operation results or block arguments, in MLIR has a type
 defined by the type system. MLIR has an open type system with no fixed list of types,
 and there are no restrictions on the abstractions they represent. For example, take
-the following [Arithmetic AddI operation](Dialects/ArithOps.md#arithaddi-mlirarithaddiop):
+the following [Arithmetic AddI operation](../Dialects/ArithOps.md#arithaddi-mlirarithaddiop):
 
 ```mlir
   %result = arith.addi %lhs, %rhs : i64
 ```
 
 It takes two input SSA values (`%lhs` and `%rhs`), and returns a single SSA
 value (`%result`). The inputs and outputs of this operation are of type `i64`,
-which is an instance of the [Builtin IntegerType](Dialects/Builtin.md#integertype).
+which is an instance of the [Builtin IntegerType](../Dialects/Builtin.md#integertype).
 
 ## Attributes and Types
 
 The C++ Attribute and Type classes in MLIR (like Ops, and many other things) are
 value-typed. This means that instances of `Attribute` or `Type` are passed
 around by-value, as opposed to by-pointer or by-reference. The `Attribute` and
 `Type` classes act as wrappers around internal storage objects that are uniqued
 within an instance of an `MLIRContext`.

 
 Starting the definition of a new attribute or type simply requires adding a
 specialization for either the `AttrDef` or `TypeDef` class respectively. Instances
 of the classes correspond to unqiue Attribute or Type classes.
 
 Below show cases an example Attribute and Type definition. We generally recommend
 defining Attribute and Type classes in different `.td` files to better encapsulate
 the different constructs, and define a proper layering between them. This
-recommendation extends to all of the MLIR constructs, including [Interfaces](Interfaces.md),
+recommendation extends to all of the MLIR constructs, including [Interfaces](../Interfaces.md),
 Operations, etc.
 
 ```tablegen
 // Include the definition of the necessary tablegen constructs for defining
 // our types.
 include "mlir/IR/AttrTypeBase.td"
 
 // It's common to define a base classes for types in the same dialect. This

 - `AttributeSelfTypeParameter` is a special `AttrParameter` that represents
   parameters derived from the optional trailing type on attributes.
 
 ### Traits
 
 Similarly to operations, Attribute and Type classes may attach `Traits` that
 provide additional mixin methods and other data. `Trait`s may be attached via
 the trailing template argument, i.e. the `traits` list parameter in the example
-above. See the main [`Trait`](Traits.md) documentation for more information
+above. See the main [`Trait`](../Traits.md) documentation for more information
 on defining and using traits.
 
 ### Interfaces
 
 Attribute and Type classes may attach `Interfaces` to provide an virtual
 interface into the Attribute or Type. `Interfaces` are added in the same way as
 [Traits](#Traits), by using the `traits` list template parameter of the
-`AttrDef` or `TypeDef`. See the main [`Interface`](Interfaces.md)
+`AttrDef` or `TypeDef`. See the main [`Interface`](../Interfaces.md)
 documentation for more information on defining and using interfaces.
 
 ### Builders
 
 For each attribute or type, there are a few builders(`get`/`getChecked`)
 automatically generated based on the parameters of the type. These are used to
 construct instances of the corresponding attribute or type. For example, given
 the following definition:

mlir/docs/DefiningDialects/Operations.md

 # Operation Definition Specification (ODS)
 
 In addition to specializing the `mlir::Op` C++ template, MLIR also supports
 defining operations and data types in a table-driven manner. This is achieved
 via [TableGen][TableGen], which is both a generic language and its tooling to
 maintain records of domain-specific information. Facts regarding an operation
 are specified concisely into a TableGen record, which will be expanded into an
 equivalent `mlir::Op` C++ template specialization at compiler build time.
 
 This manual explains in detail all the available mechanisms for defining
 operations in such a table-driven manner. It aims to be a specification instead
 of a tutorial. Please refer to
-[Quickstart tutorial to adding MLIR graph rewrite](Tutorials/QuickstartRewrites.md)
+[Quickstart tutorial to adding MLIR graph rewrite](../Tutorials/QuickstartRewrites.md)
 for the latter.
 
 In addition to detailing each mechanism, this manual also tries to capture best
 practices. They are rendered as quoted bullet points.
 
 [TOC]
 
 ## Motivation

 `VariadicSuccessor<...>` can be used for successors. Variadic successors can
 currently only be specified as the last successor in the successor list.
 
 ### Operation traits and constraints
 
 Traits are operation properties that affect syntax or semantics. MLIR C++ models
 various traits in the `mlir::OpTrait` namespace.
 
-Both operation traits, [interfaces](Interfaces.md/#utilizing-the-ods-framework),
+Both operation traits, [interfaces](../Interfaces.md/#utilizing-the-ods-framework),
 and constraints involving multiple operands/attributes/results are provided as
 the third template parameter to the `Op` class. They should be deriving from
 the `OpTrait` class. See [Constraints](#constraints) for more information.
 
 ### Builder methods
 
 For each operation, there are a few builders automatically generated based on
 the arguments and returns types. For example, given the following op definition:
*   `custom` < UserDirective > ( Params )
 
     -   Represents a custom directive implemented by the user in C++.
     -   See the [Custom Directives](#custom-directives) section below for more
         details.
 
 *   `functional-type` ( inputs , outputs )
 
     -   Formats the `inputs` and `outputs` arguments as a
-        [function type](Dialects/Builtin.md/#functiontype).
+        [function type](../Dialects/Builtin.md/#functiontype).
     -   The constraints on `inputs` and `outputs` are the same as the `input` of
         the `type` directive.
 
 *   `oilist` ( \`keyword\` elements | \`otherKeyword\` elements ...)
 
     -   Represents an optional order-independent list of clauses. Each clause
         has a keyword and corresponding assembly format.
     -   Each clause can appear 0 or 1 time (in any order).
def ReturnOp : ... {
   // We only print the operands and types if there are a non-zero number
   // of operands.
   let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?";
 }
 ```
 
 ##### Unit Attributes
 
-In MLIR, the [`unit` Attribute](Dialects/Builtin.md/#unitattr) is special in that it
+In MLIR, the [`unit` Attribute](../Dialects/Builtin.md/#unitattr) is special in that it
 only has one possible value, i.e. it derives meaning from its existence. When a
 unit attribute is used to anchor an optional group and is not the first element
 of the group, the presence of the unit attribute can be directly correlated with
 the presence of the optional group itself. As such, in these situations the unit
 attribute will not be printed or present in the output and will be automatically
 inferred when parsing by the presence of the optional group itself.
 
 For example, the following operation:

 *   MLIR allows both defined and undefined ops.
     *   Defined ops should have fixed semantics and could have a corresponding
         reference implementation defined.
     *   Dialects are under full control of the dialect owner and normally live
         with the framework of the dialect.
 *   The op's traits (e.g., commutative) are modelled along with the op in the
     registry.
 *   The op's operand/return type constraints are modelled along with the op in
-    the registry (see [Shape inference](ShapeInference.md) discussion below),
+    the registry (see [Shape inference](../ShapeInference.md) discussion below),
     this allows (e.g.) optimized concise syntax in textual dumps.
 *   Behavior of the op is documented along with the op with a summary and a
     description. The description is written in markdown and extracted for
     inclusion in the generated LangRef section of the dialect.
 *   The generic assembly form of printing and parsing is available as normal,
     but a custom parser and printer can either be specified or automatically
     generated from an optional string representation showing the mapping of the
     "assembly" string to operands/type.
*   Reference implementation may be provided along with the op definition.
     TODO: document expectation if the dependent op's definition changes.
 
 [TableGen]: https://llvm.org/docs/TableGen/index.html
 [TableGenProgRef]: https://llvm.org/docs/TableGen/ProgRef.html
 [TableGenBackend]: https://llvm.org/docs/TableGen/BackEnds.html#introduction
 [OpBase]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/OpBase.td
 [OpDefinitionsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
 [EnumsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/EnumsGen.cpp
-[StringAttr]: Dialects/Builtin.md/#stringattr
-[IntegerAttr]: Dialects/Builtin.md/#integertype
+[StringAttr]: ../Dialects/Builtin.md/#stringattr
+[IntegerAttr]: ../Dialects/Builtin.md/#integertype
 [AttrClasses]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/Attributes.h

mlir/docs/DefiningDialects/_index.md

 # Defining Dialects
 
-This document describes how to define [Dialects](LangRef.md/#dialects).
+This document describes how to define [Dialects](../LangRef.md/#dialects).
 
 [TOC]
 
 ## LangRef Refresher
 
 Before diving into how to define these constructs, below is a quick refresher
-from the [MLIR LangRef](LangRef.md).
+from the [MLIR LangRef](../LangRef.md).
 
 Dialects are the mechanism by which to engage with and extend the MLIR
-ecosystem. They allow for defining new [attributes](LangRef.md#attributes),
-[operations](LangRef.md#operations), and [types](LangRef.md#type-system).
+ecosystem. They allow for defining new [attributes](../LangRef.md#attributes),
+[operations](../LangRef.md#operations), and [types](../LangRef.md#type-system).
 Dialects are used to model a variety of different abstractions; from traditional
-[arithmetic](Dialects/ArithOps.md) to
-[pattern rewrites](Dialects/PDLOps.md); and is one of the most fundamental
+[arithmetic](../Dialects/ArithOps.md) to
+[pattern rewrites](../Dialects/PDLOps.md); and is one of the most fundamental
 aspects of MLIR.
 
 ## Defining a Dialect
 
 At the most fundamental level, defining a dialect in MLIR is as simple as
 specializing the
 [C++ `Dialect` class](https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/Dialect.h).
 That being said, MLIR provides a powerful declaratively specification mechanism via
 [TableGen](https://llvm.org/docs/TableGen/index.html); a generic language with
 tooling to maintain records of domain-specific information; that simplifies the
 definition process by automatically generating all of the necessary boilerplate
 C++ code, significantly reduces maintainence burden when changing aspects of dialect
 definitions, and also provides additional tools on top (such as
 documentation generation). Given the above, the declarative specification is the
 expected mechanism for defining new dialects, and is the method detailed within
 this document. Before continuing, it is highly recommended that users review the
 [TableGen Programmer's Reference](https://llvm.org/docs/TableGen/ProgRef.html)
 for an introduction to its syntax and constructs.
 
 Below showcases an example simple Dialect definition. We generally recommend defining
 the Dialect class in a different `.td` file from the attributes, operations, types,
 and other sub-components of the dialect to establish a proper layering between
 the various different dialect components. It also prevents situations where you may
 inadvertantly generate multiple definitions for some constructs. This recommendation
-extends to all of the MLIR constructs, including [Interfaces](Interfaces.md) for example.
+extends to all of the MLIR constructs, including [Interfaces](../Interfaces.md) for example.
 
 ```tablegen
 // Include the definition of the necessary tablegen constructs for defining
 // our dialect. 
 include "mlir/IR/DialectBase.td"
 
 // Here is a simple definition of a dialect.
 def MyDialect : Dialect {

 ### `hasConstantMaterializer`: Materializing Constants from Attributes
 
 This field is utilized to materialize a constant operation from an `Attribute` value and
 a `Type`. This is generally used when an operation within this dialect has been folded,
 and a constant operation should be generated. `hasConstantMaterializer` is used to enable
 materialization, and the `materializeConstant` hook is declared on the dialect. This
 hook takes in an `Attribute` value, generally returned by `fold`, and produces a
 "constant-like" operation that materializes that value. See the
-[documentation for canonicalization](Canonicalization.md) for a more in-depth
+[documentation for canonicalization](../Canonicalization.md) for a more in-depth
 introduction to `folding` in MLIR.
 
 Constant materialization logic can then be defined in the source file:
 
 ```c++
 /// Hook to materialize a single constant operation from a given attribute value
 /// with the desired resultant type. This method should use the provided builder
 /// to create the operation without changing the insertion position. The

 ### `hasNonDefaultDestructor`: Providing a custom destructor
 
 This field should be used when the Dialect class has a custom destructor, i.e.
 when the dialect has some special logic to be run in the `~MyDialect`. In this case,
 only the declaration of the destructor is generated for the Dialect class.
 
 ### Discardable Attribute Verification
 
-As described by the [MLIR Language Reference](LangRef.md#attributes),
+As described by the [MLIR Language Reference](../LangRef.md#attributes),
 *discardable attribute* are a type of attribute that has its semantics defined
 by the dialect whose name prefixes that of the attribute. For example, if an
 operation has an attribute named `gpu.contained_module`, the `gpu` dialect
 defines the semantics and invariants, such as when and where it is valid to use,
 of that attribute. To hook into this verification for attributes that are prefixed
 by our dialect, several hooks on the Dialect may be used:
 
 #### `hasOperationAttrVerify`

 
 ```c++
 /// Return an interface model for the interface with the given `typeId` for the operation
 /// with the given name.
 void *MyDialect::getRegisteredInterfaceForOp(TypeID typeID, StringAttr opName);
 ```
 
 For a more detail description of the expected usages of this hook, view the detailed 
-[interface documentation](Interfaces.md#dialect-fallback-for-opinterface).
+[interface documentation](../Interfaces.md#dialect-fallback-for-opinterface).
 
 ### Default Attribute/Type Parsers and Printers 
 
 When a dialect registers an Attribute or Type, it must also override the respective
 `Dialect::parseAttribute`/`Dialect::printAttribute` or
 `Dialect::parseType`/`Dialect::printType` methods. In these cases, the dialect must
 explicitly handle the parsing and printing of each individual attribute or type within
 the dialect. If all of the attributes and types of the dialect provide a mnemonic,
 however, these methods may be autogenerated by using the
 `useDefaultAttributePrinterParser` and `useDefaultTypePrinterParser` fields. By default,
 these fields are set to `1`(enabled), meaning that if a dialect needs to explicitly handle the
 parser and printer of its Attributes and Types it should set these to `0` as necessary.
 
 ### Dialect-wide Canonicalization Patterns
 
-Generally, [canonicalization](Canonicalization.md) patterns are specific to individual 
+Generally, [canonicalization](../Canonicalization.md) patterns are specific to individual 
 operations within a dialect. There are some cases, however, that prompt canonicalization
 patterns to be added to the dialect-level. For example, if a dialect defines a canonicalization
 pattern that operates on an interface or trait, it can be beneficial to only add this pattern
 once, instead of duplicating per-operation that implements that interface. To enable the
 generation of this hook, the `hasCanonicalizer` field may be used. This will declare
 the `getCanonicalizationPatterns` method on the dialect, which has the form:
 
 ```c++
 /// Return the canonicalization patterns for this dialect:
 void MyDialect::getCanonicalizationPatterns(RewritePatternSet &results) const;
 ```
 
-See the documentation for [Canonicalization in MLIR](Canonicalization.md) for a much more 
+See the documentation for [Canonicalization in MLIR](../Canonicalization.md) for a much more 
 detailed description about canonicalization patterns.
 
 ## Defining an Extensible dialect
 
 This section documents the design and API of the extensible dialects. Extensible
 dialects are dialects that can be extended with new operations and types defined
 at runtime. This allows for users to define dialects via with meta-programming,
 or from another language, without having to recompile C++ code.

mlir/docs/Dialects/SPIR-V.md

 [ImageType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypeImage
 [PointerType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypePointer
 [RuntimeArrayType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypeRuntimeArray
 [SampledImageType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypeSampledImage
 [MlirDialectConversion]: ../DialectConversion.md
 [StructType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#Structure
 [SpirvTools]: https://github.com/KhronosGroup/SPIRV-Tools
 [Rationale]: ../Rationale/Rationale.md/#block-arguments-vs-phi-nodes
-[ODS]: ../OpDefinitions.md
+[ODS]: ../DefiningDialects/Operations.md
 [GreedyPatternRewriter]: https://github.com/llvm/llvm-project/blob/main/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp
 [MlirDialectConversionTypeConversion]: ../DialectConversion.md/#type-converter
 [MlirDialectConversionRewritePattern]: ../DialectConversion.md/#conversion-patterns
 [MlirDialectConversionSignatureConversion]: ../DialectConversion.md/#region-signature-conversion
 [MlirOpInterface]: ../Interfaces/#operation-interfaces
 [MlirIntegerType]: Builtin.md/#integertype
 [MlirVectorType]: Builtin.md/#vectortype
 [MlirMemrefType]: Builtin.md/#memreftype

 [MlirSpirvBase]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/SPIRV/IR/SPIRVBase.td
 [MlirSpirvPasses]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/SPIRV/Transforms/Passes.h
 [MlirSpirvConversion]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/SPIRV/Transforms/SPIRVConversion.h
 [MlirSpirvAbi]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/SPIRV/IR/TargetAndABI.h
 [MlirSpirvOpsCpp]: https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/SPIRV/IR/SPIRVOps.cpp
 [GitHubDialectTracking]: https://github.com/tensorflow/mlir/issues/302
 [GitHubLoweringTracking]: https://github.com/tensorflow/mlir/issues/303
 [GenSpirvUtilsPy]: https://github.com/llvm/llvm-project/blob/main/mlir/utils/spirv/gen_spirv_dialect.py
-[CustomTypeAttrTutorial]: ../Tutorials/DefiningAttributesAndTypes.md
+[CustomTypeAttrTutorial]: ../DefiningDialects/AttributesAndTypes.md
 [VulkanExtensionPhysicalStorageBuffer]: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_physical_storage_buffer.html
 [VulkanExtensionVariablePointers]: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_variable_pointers.html
 [VulkanSpirv]: https://renderdoc.org/vkspec_chunked/chap40.html#spirvenv
 [VulkanShaderInterface]: https://renderdoc.org/vkspec_chunked/chap14.html#interfaces-resources
 [VulkanShaderInterfaceStorageClass]: https://renderdoc.org/vkspec_chunked/chap15.html#interfaces
 [VulkanResourceLimits]: https://renderdoc.org/vkspec_chunked/chap36.html#limits
 [VulkanGPUInfoMaxPerStageDescriptorStorageBuffers]: https://vulkan.gpuinfo.org/displaydevicelimit.php?name=maxPerStageDescriptorStorageBuffers&platform=android
 [VulkanPushConstants]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCmdPushConstants.html

mlir/docs/Dialects/_index.md

 # Dialects
 
 This section contains documentation for core and contributed dialects available
 from the MLIR repository. The description for each dialect includes content
 automatically generated from the dialect's
-[Operation Definition Specification (ODS)](../OpDefinitions.md).
+[Definition Specification (ODS)](../DefiningDialects/_index.md).

mlir/docs/Interfaces.md

void *TestDialect::getRegisteredInterfaceForOp(TypeID typeID,
   return nullptr;
 }
 ```
 
 #### Utilizing the ODS Framework
 
 Note: Before reading this section, the reader should have some familiarity with
 the concepts described in the
-[`Operation Definition Specification`](OpDefinitions.md) documentation.
+[`Operation Definition Specification`](DefiningDialects/Operations.md) documentation.
 
 As detailed above, [Interfaces](#attributeoperationtype-interfaces) allow for
 attributes, operations, and types to expose method calls without requiring that
 the caller know the specific derived type. The downside to this infrastructure,
 is that it requires a bit of boiler plate to connect all of the pieces together.
 MLIR provides a mechanism with which to defines interfaces declaratively in ODS,
 and have the C++ definitions auto-generated.
 

mlir/docs/LangRef.md

 ```mlir
 // A tensorflow string type.
 !tf.string
 
 // A type with complex components.
 !foo.something<abcd>
 ```
 
-See [here](AttributesAndTypes.md) to learn how to define dialect types.
+See [here](DefiningDialects/AttributesAndTypes.md) to learn how to define dialect types.
 
 ### Builtin Types
 
 The [builtin dialect](Dialects/Builtin.md) defines a set of types that are
 directly usable by any other dialect in MLIR. These types cover a range from
 primitive integer and floating-point types, function types, and more.
 
 ## Attributes

 Dialect attributes that are simple enough may use a prettier format, which unwraps
 part of the syntax into an equivalent, but lighter weight form:
 
 ```mlir
 // A string attribute.
 #foo.string<"">
 ```
 
-See [here](AttributesAndTypes.md) on how to define dialect attribute values.
+See [here](DefiningDialects/AttributesAndTypes.md) on how to define dialect attribute values.
 
 ### Builtin Attribute Values
 
 The [builtin dialect](Dialects/Builtin.md) defines a set of attribute values
 that are directly usable by any other dialect in MLIR. These types cover a range
 from primitive integer and floating-point values, attribute dictionaries, dense
 multi-dimensional arrays, and more.

mlir/docs/PassManagement.md

 
 In order to support round-tripping a pass to the textual representation using
 `OpPassManager::printAsTextualPipeline(raw_ostream&)`, override `StringRef
 Pass::getArgument()` to specify the argument used when registering a pass.
 
 ## Declarative Pass Specification
 
 Some aspects of a Pass may be specified declaratively, in a form similar to
-[operations](OpDefinitions.md). This specification simplifies several mechanisms
+[operations](DefiningDialects/Operations.md). This specification simplifies several mechanisms
 used when defining passes. It can be used for generating pass registration
 calls, defining boilerplate pass utilities, and generating pass documentation.
 
 Consider the following pass specified in C++:
 
 ```c++
 struct MyPass : PassWrapper<MyPass, OperationPass<ModuleOp>> {
   MyPass() = default;

mlir/docs/Rationale/RationaleLinalgDialect.md

 [Linalg section](https://llvm.org/devmtg/2019-04/slides/Tutorial-AminiVasilacheZinenko-MLIR.pdf)
 of the first [MLIR Tutorial](https://www.youtube.com/watch?v=cyICUIZ56wQ).
 
 ### Evolution
 Since the initial implementation, the design has evolved with, and partially
 driven the evolution of the core MLIR infrastructure to use
 [Regions](../LangRef.md/#regions),
 [OpInterfaces](../Interfaces.md),
-[ODS](../OpDefinitions.md) and
+[ODS](../DefiningDialects/Operations.md) and
 [Declarative Rewrite Rules](../DeclarativeRewrites.md)
 among others. The approach adopted by Linalg was extended to become
 [StructuredOps abstractions](
 https://drive.google.com/drive/u/0/folders/1sRAsgsd8Bvpm_IxREmZf2agsGU2KvrK-),
 with Linalg becoming its incarnation on tensors and buffers.
 It is complemented by the
 [Vector dialect](../Dialects/Vector.md),
 which defines structured operations on vectors, following the same rationale and

mlir/docs/Traits.md

 class MyTrait : public TraitBase<ConcreteType, MyTrait> {
 };
 ```
 
 Operation traits may also provide a `verifyTrait` or `verifyRegionTrait` hook
 that is called when verifying the concrete operation. The difference between
 these two is that whether the verifier needs to access the regions, if so, the
 operations in the regions will be verified before the verification of this
-trait. The [verification order](OpDefinitions.md/#verification-ordering)
+trait. The [verification order](DefiningDialects/Operations.md/#verification-ordering)
 determines when a verifier will be invoked.
 
 ```c++
 template <typename ConcreteType>
 class MyTrait : public OpTrait::TraitBase<ConcreteType, MyTrait> {
 public:
   /// Override the 'verifyTrait' hook to add additional verification on the
   /// concrete operation.

 class MyOp : public Op<MyOp, MyTrait, MyParametricTrait<10>::Impl> {};
 /// Here we define 'MyType' along with the 'MyTrait' and `MyParametric trait
 /// classes we defined previously.
 class MyType : public Type::TypeBase<MyType, ..., MyTrait, MyParametricTrait<10>::Impl> {};
 ```
 
 ### Attaching Operation Traits in ODS
 
-To use an operation trait in the [ODS](OpDefinitions.md) framework, we need to
+To use an operation trait in the [ODS](DefiningDialects/Operations.md) framework, we need to
 provide a definition of the trait class. This can be done using the
 `NativeOpTrait` and `ParamNativeOpTrait` classes. `ParamNativeOpTrait` provides
 a mechanism in which to specify arguments to a parametric trait class with an
 internal `Impl`.
 
 ```tablegen
 // The argument is the c++ trait class name.
 def MyTrait : NativeOpTrait<"MyTrait">;
 
 // The first argument is the parent c++ class name. The second argument is a
 // string containing the parameter list.
 class MyParametricTrait<int prop>
   : NativeOpTrait<"MyParametricTrait", !cast<string>(!head(parameters))>;
 ```
 
 These can then be used in the `traits` list of an op definition:
 
 ```tablegen
 def OpWithInferTypeInterfaceOp : Op<...[MyTrait, MyParametricTrait<10>]> { ... }
 ```
 
-See the documentation on [operation definitions](OpDefinitions.md) for more
+See the documentation on [operation definitions](DefiningDialects/Operations.md) for more
 details.
 
 ## Using a Trait
 
 Traits may be used to provide additional methods, static fields, or other
 information directly on the concrete object. `Traits` internally become `Base`
 classes of the concrete operation, so all of these are directly accessible. To
 expose this information opaquely to transformations and analyses,

mlir/docs/Tutorials/CreatingADialect.md

 # Creating a Dialect
 
 [TOC]
 
 Public dialects are typically separated into at least 3 directories:
 * mlir/include/mlir/Dialect/Foo   (for public include files)
 * mlir/lib/Dialect/Foo            (for sources)
 * mlir/lib/Dialect/Foo/IR         (for operations)
 * mlir/lib/Dialect/Foo/Transforms (for transforms)
 * mlir/test/Dialect/Foo           (for tests)
 
 Along with other public headers, the 'include' directory contains a
-TableGen file in the [ODS format](../OpDefinitions.md), describing the
+TableGen file in the [ODS format](../DefiningDialects/Operations.md), describing the
 operations in the dialect.  This is used to generate operation
 declarations (FooOps.h.inc) and definitions (FooOps.cpp.inc) and
 operation interface declarations (FooOpsInterfaces.h.inc) and
 definitions (FooOpsInterfaces.cpp.inc).
 
 The 'IR' directory typically contains implementations of functions for
 the dialect which are not automatically generated by ODS.  These are
 typically defined in FooDialect.cpp, which includes FooOps.cpp.inc and

mlir/docs/Tutorials/QuickstartRewrites.md

 # Quickstart tutorial to adding MLIR graph rewrite
 
 This document will present a quickstart to adding graph rewrites. We shall start
 by defining an operation, showing multiple ways to define the rewrite using
 patterns, as well as defining the rewrite using a graph walker (note: using
 patterns and the rewrite engine is preferred, showing the walker is for
 demonstration purposes).
 
 See [MLIR specification](../LangRef.md) for more information about MLIR, the
 structure of the IR, operations, etc. See
-[Table-driven Operation Definition](../OpDefinitions.md) and
+[Table-driven Operation Definition](../DefiningDialects/Operations.md) and
 [Declarative Rewrite Rule](../DeclarativeRewrites.md) for the detailed explanation
 of all available mechanisms for defining operations and rewrites in a
 table-driven manner.
 
 ## Adding operation
 
 An operation in MLIR is specified using a definition in
 [TableGen](https://llvm.org/docs/TableGen/index.html) file. TableGen is a

mlir/docs/Tutorials/Toy/Ch-2.md

assert(internalOperation == operation &&
          "these operation instances are the same");
 }
 ```
 
 ### Using the Operation Definition Specification (ODS) Framework
 
 In addition to specializing the `mlir::Op` C++ template, MLIR also supports
 defining operations in a declarative manner. This is achieved via the
-[Operation Definition Specification](../../OpDefinitions.md) framework. Facts
+[Operation Definition Specification](../../DefiningDialects/Operations.md) framework. Facts
 regarding an operation are specified concisely into a TableGen record, which
 will be expanded into an equivalent `mlir::Op` C++ template specialization at
 compile time. Using the ODS framework is the desired way for defining operations
 in MLIR given the simplicity, conciseness, and general stability in the face of
 C++ API changes.
 
 Lets see how to define the ODS equivalent of our ConstantOp:
 
class Toy_Op<string mnemonic, list<Trait> traits = []> :
     Op<Toy_Dialect, mnemonic, traits>;
 ```
 
 With all of the preliminary pieces defined, we can begin to define the constant
 operation.
 
 We define a toy operation by inheriting from our base 'Toy_Op' class above. Here
 we provide the mnemonic and a list of traits for the operation. The
-[mnemonic](../../OpDefinitions.md/#operation-name) here matches the one given in
+[mnemonic](../../DefiningDialects/Operations.md/#operation-name) here matches the one given in
 `ConstantOp::getOperationName` without the dialect prefix; `toy.`. Missing here
 from our C++ definition are the `ZeroOperands` and `OneResult` traits; these
 will be automatically inferred based upon the `arguments` and `results` fields
 we define later.
 
 ```tablegen
 def ConstantOp : Toy_Op<"constant"> {
 }

 
 Depending on the selected action, this will print either the `ConstantOp` class
 declaration or its implementation. Comparing this output to the hand-crafted
 implementation is incredibly useful when getting started with TableGen.
 
 #### Defining Arguments and Results
 
 With the shell of the operation defined, we can now provide the
-[inputs](../../OpDefinitions.md/#operation-arguments) and
-[outputs](../../OpDefinitions.md/#operation-results) to our operation. The
+[inputs](../../DefiningDialects/Operations.md/#operation-arguments) and
+[outputs](../../DefiningDialects/Operations.md/#operation-results) to our operation. The
 inputs, or arguments, to an operation may be attributes or types for SSA operand
 values. The results correspond to a set of types for the values produced by the
 operation:
 
 ```tablegen
 def ConstantOp : Toy_Op<"constant"> {
   // The constant operation takes an attribute as the only input.
   // `F64ElementsAttr` corresponds to a 64-bit floating-point ElementsAttr.
   let arguments = (ins F64ElementsAttr:$value);
 
   // The constant operation returns a single value of TensorType.
   // F64Tensor corresponds to a 64-bit floating-point TensorType.
   let results = (outs F64Tensor);
 }
 ```
 
 By providing a name to the arguments or results, e.g. `$value`, ODS will
 automatically generate a matching accessor: `DenseElementsAttr
 ConstantOp::value()`.
 
 #### Adding Documentation
 
 The next step after defining the operation is to document it. Operations may
 provide
-[`summary` and `description`](../../OpDefinitions.md/#operation-documentation)
+[`summary` and `description`](../../DefiningDialects/Operations.md/#operation-documentation)
 fields to describe the semantics of the operation. This information is useful
 for users of the dialect and can even be used to auto-generate Markdown
 documents.
 
 ```tablegen
 def ConstantOp : Toy_Op<"constant"> {
   // Provide a summary and description for this operation. This can be used to
   // auto-generate documentation of the operations within our dialect.

 
 At this point we've already covered a majority of the original C++ operation
 definition. The next piece to define is the verifier. Luckily, much like the
 named accessor, the ODS framework will automatically generate a lot of the
 necessary verification logic based upon the constraints we have given. This
 means that we don't need to verify the structure of the return type, or even the
 input attribute `value`. In many cases, additional verification is not even
 necessary for ODS operations. To add additional verification logic, an operation
-can override the [`verifier`](../../OpDefinitions.md/#custom-verifier-code)
+can override the [`verifier`](../../DefiningDialects/Operations.md/#custom-verifier-code)
 field. The `verifier` field allows for defining a C++ code blob that will be run
 as part of `ConstantOp::verify`. This blob can assume that all of the other
 invariants of the operation have already been verified:
 
 ```tablegen
 def ConstantOp : Toy_Op<"constant"> {
   // Provide a summary and description for this operation. This can be used to
   // auto-generate documentation of the operations within our dialect.

 }
 ```
 
 #### Attaching `build` Methods
 
 The final missing component here from our original C++ example are the `build`
 methods. ODS can generate some simple build methods automatically, and in this
 case it will generate our first build method for us. For the rest, we define the
-[`builders`](../../OpDefinitions.md/#custom-builder-methods) field. This field
+[`builders`](../../DefiningDialects/Operations.md/#custom-builder-methods) field. This field
 takes a list of `OpBuilder` objects that take a string corresponding to a list
 of C++ parameters, as well as an optional code block that can be used to specify
 the implementation inline.
 
 ```tablegen
 def ConstantOp : Toy_Op<"constant"> {
   ...
 
module {
   }) {sym_name = "main", type = () -> ()} : () -> () loc("test/Examples/Toy/Ch2/codegen.toy":8:1)
 } loc(unknown)
 ```
 
 One thing to notice here is that all of our Toy operations are printed using the
 generic assembly format. This format is the one shown when breaking down
 `toy.transpose` at the beginning of this chapter. MLIR allows for operations to
 define their own custom assembly format, either
-[declaratively](../../OpDefinitions.md/#declarative-assembly-format) or
+[declaratively](../../DefiningDialects/Operations.md/#declarative-assembly-format) or
 imperatively via C++. Defining a custom assembly format allows for tailoring the
 generated IR into something a bit more readable by removing a lot of the fluff
 that is required by the generic format. Let's walk through an example of an
 operation format that we would like to simplify.
 
 ##### `toy.print`
 
 The current form of `toy.print` is a little verbose. There are a lot of
mlir::ParseResult PrintOp::parse(mlir::OpAsmParser &parser,
   if (parser.resolveOperand(inputOperand, inputType, result.operands))
     return mlir::failure();
 
   return mlir::success();
 }
 ```
 
 With the C++ implementation defined, let's see how this can be mapped to the
-[declarative format](../../OpDefinitions.md/#declarative-assembly-format). The
+[declarative format](../../DefiningDialects/Operations.md/#declarative-assembly-format). The
 declarative format is largely composed of three different components:
 
 *   Directives
     -   A type of builtin function, with an optional set of arguments.
 *   Literals
     -   A keyword or punctuation surrounded by \`\`.
 *   Variables
     -   An entity that has been registered on the operation itself, i.e. an
def PrintOp : Toy_Op<"print"> {
 
   // In the following format we have two directives, `attr-dict` and `type`.
   // These correspond to the attribute dictionary and the type of a given
   // variable represectively.
   let assemblyFormat = "$input attr-dict `:` type($input)";
 }
 ```
 
-The [declarative format](../../OpDefinitions.md/#declarative-assembly-format) has
+The [declarative format](../../DefiningDialects/Operations.md/#declarative-assembly-format) has
 many more interesting features, so be sure to check it out before implementing a
 custom format in C++. After beautifying the format of a few of our operations we
 now get a much more readable:
 
 ```mlir
 module {
   toy.func @multiply_transpose(%arg0: tensor<*xf64>, %arg1: tensor<*xf64>) -> tensor<*xf64> {
     %0 = toy.transpose(%arg0 : tensor<*xf64>) to tensor<*xf64> loc("test/Examples/Toy/Ch2/codegen.toy":5:10)
toy.func @main() {
     toy.return loc("test/Examples/Toy/Ch2/codegen.toy":8:1)
   } loc("test/Examples/Toy/Ch2/codegen.toy":8:1)
 } loc(unknown)
 ```
 
 Above we introduce several of the concepts for defining operations in the ODS
 framework, but there are many more that we haven't had a chance to: regions,
 variadic operands, etc. Check out the
-[full specification](../../OpDefinitions.md) for more details.
+[full specification](../../DefiningDialects/Operations.md) for more details.
 
 ## Complete Toy Example
 
 We can now generate our "Toy IR". You can build `toyc-ch2` and try yourself on
 the above example: `toyc-ch2 test/Examples/Toy/Ch2/codegen.toy -emit=mlir
 -mlir-print-debuginfo`. We can also check our RoundTrip: `toyc-ch2
 test/Examples/Toy/Ch2/codegen.toy -emit=mlir -mlir-print-debuginfo 2>
 codegen.mlir` followed by `toyc-ch2 codegen.mlir -emit=mlir`. You should also
 use `mlir-tblgen` on the final definition file and study the generated C++ code.
 
 At this point, MLIR knows about our Toy dialect and operations. In the
 [next chapter](Ch-3.md), we will leverage our new dialect to implement some
 high-level language-specific analyses and transformations for the Toy language.

mlir/docs/Tutorials/Toy/Ch-3.md

struct SimplifyRedundantTranspose : public mlir::OpRewritePattern<TransposeOp> {
   }
 };
 ```
 
 The implementation of this rewriter is in `ToyCombine.cpp`. The
 [canonicalization pass](../../Canonicalization.md) applies transformations
 defined by operations in a greedy, iterative manner. To ensure that the
 canonicalization pass applies our new transform, we set
-[hasCanonicalizer = 1](../../OpDefinitions.md/#hascanonicalizer) and register the
+[hasCanonicalizer = 1](../../DefiningDialects/Operations.md/#hascanonicalizer) and register the
 pattern with the canonicalization framework.
 
 ```c++
 // Register our patterns for rewrite by the Canonicalization framework.
 void TransposeOp::getCanonicalizationPatterns(
     RewritePatternSet &results, MLIRContext *context) {
   results.add<SimplifyRedundantTranspose>(context);
 }

mlir/docs/Tutorials/Toy/Ch-5.md

*   Generate `load` operations from the buffer
     optimizations have been performed.
 
 *   Generate a new version of `toy.print` that operates on the lowered type
 
     Another option would be to have another, lowered, variant of `toy.print`
     that operates on the lowered type. The benefit of this option is that there
     is no hidden, unnecessary copy to the optimizer. The downside is that
     another operation definition is needed that may duplicate many aspects of
-    the first. Defining a base class in [ODS](../../OpDefinitions.md) may
+    the first. Defining a base class in [ODS](../../DefiningDialects/Operations.md) may
     simplify this, but you still need to treat these operations separately.
 
 *   Update `toy.print` to allow for operating on the lowered type
 
     A third option is to update the current definition of `toy.print` to allow
     for operating the on the lowered type. The benefit of this approach is that
     it is simple, does not introduce an additional hidden copy, and does not
     require another operation definition. The downside to this option is that it

mlir/docs/Tutorials/Toy/Ch-7.md

toy.func @main() {
     toy.return
   }
 }
 ```
 
 You can build `toyc-ch7` and try yourself: `toyc-ch7
 test/Examples/Toy/Ch7/struct-codegen.toy -emit=mlir`. More details on defining
 custom types can be found in
-[DefiningAttributesAndTypes](../DefiningAttributesAndTypes.md).
+[DefiningAttributesAndTypes](../../DefiningDialects/AttributesAndTypes.md).