[Mlir-commits] [mlir] 1294fa6 - [mlir][docs] Group the docs for defining dialect components
River Riddle
llvmlistbot at llvm.org
Fri Dec 2 13:38:34 PST 2022
Author: River Riddle
Date: 2022-12-02T13:38:14-08:00
New Revision: 1294fa697176c244e92e72c0b01fd3b5e3a06477
URL: https://github.com/llvm/llvm-project/commit/1294fa697176c244e92e72c0b01fd3b5e3a06477
DIFF: https://github.com/llvm/llvm-project/commit/1294fa697176c244e92e72c0b01fd3b5e3a06477.diff
LOG: [mlir][docs] Group the docs for defining dialect components
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.
Differential Revision: https://reviews.llvm.org/D137594
Added:
mlir/docs/DefiningDialects/AttributesAndTypes.md
mlir/docs/DefiningDialects/Operations.md
mlir/docs/DefiningDialects/_index.md
Modified:
mlir/docs/Canonicalization.md
mlir/docs/DeclarativeRewrites.md
mlir/docs/Dialects/SPIR-V.md
mlir/docs/Dialects/_index.md
mlir/docs/Interfaces.md
mlir/docs/LangRef.md
mlir/docs/PassManagement.md
mlir/docs/Rationale/RationaleLinalgDialect.md
mlir/docs/Traits.md
mlir/docs/Tutorials/CreatingADialect.md
mlir/docs/Tutorials/QuickstartRewrites.md
mlir/docs/Tutorials/Toy/Ch-2.md
mlir/docs/Tutorials/Toy/Ch-3.md
mlir/docs/Tutorials/Toy/Ch-5.md
mlir/docs/Tutorials/Toy/Ch-7.md
Removed:
mlir/docs/AttributesAndTypes.md
mlir/docs/DefiningDialects.md
mlir/docs/OpDefinitions.md
################################################################################
diff --git a/mlir/docs/Canonicalization.md b/mlir/docs/Canonicalization.md
index 71707cac41c64..1d3f053f32936 100644
--- a/mlir/docs/Canonicalization.md
+++ b/mlir/docs/Canonicalization.md
@@ -69,7 +69,7 @@ infrastructure allows for expressing many
diff erent 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:
@@ -119,7 +119,7 @@ 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
diff erent form,
depending on the structure of the operation.
@@ -202,7 +202,7 @@ 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
diff --git a/mlir/docs/DeclarativeRewrites.md b/mlir/docs/DeclarativeRewrites.md
index 6443fce9297c8..6a9016a47cf46 100644
--- a/mlir/docs/DeclarativeRewrites.md
+++ b/mlir/docs/DeclarativeRewrites.md
@@ -2,7 +2,7 @@
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
@@ -15,7 +15,7 @@ instead of a tutorial. Please refer to
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]
diff --git a/mlir/docs/AttributesAndTypes.md b/mlir/docs/DefiningDialects/AttributesAndTypes.md
similarity index 98%
rename from mlir/docs/AttributesAndTypes.md
rename to mlir/docs/DefiningDialects/AttributesAndTypes.md
index 52b00739a5b13..d794b942f788c 100644
--- a/mlir/docs/AttributesAndTypes.md
+++ b/mlir/docs/DefiningDialects/AttributesAndTypes.md
@@ -1,21 +1,21 @@
# 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.
@@ -24,7 +24,7 @@ names to attribute values.
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
@@ -32,7 +32,7 @@ the following [Arithmetic AddI operation](Dialects/ArithOps.md#arithaddi-mlirari
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
@@ -66,7 +66,7 @@ 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
diff erent `.td` files to better encapsulate
the
diff erent 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
@@ -281,7 +281,7 @@ MLIR includes several specialized classes for common situations:
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
@@ -289,7 +289,7 @@ on defining and using traits.
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
diff --git a/mlir/docs/OpDefinitions.md b/mlir/docs/DefiningDialects/Operations.md
similarity index 99%
rename from mlir/docs/OpDefinitions.md
rename to mlir/docs/DefiningDialects/Operations.md
index 3acbf8360f64d..c131047e3978a 100644
--- a/mlir/docs/OpDefinitions.md
+++ b/mlir/docs/DefiningDialects/Operations.md
@@ -10,7 +10,7 @@ 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
@@ -358,7 +358,7 @@ currently only be specified as the last successor in the successor list.
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.
@@ -657,7 +657,7 @@ The available directives are as follows:
* `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.
@@ -900,7 +900,7 @@ def ReturnOp : ... {
##### 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
@@ -1619,7 +1619,7 @@ requirements that were desirable:
* 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
@@ -1648,6 +1648,6 @@ requirements that were desirable:
[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
diff --git a/mlir/docs/DefiningDialects.md b/mlir/docs/DefiningDialects/_index.md
similarity index 96%
rename from mlir/docs/DefiningDialects.md
rename to mlir/docs/DefiningDialects/_index.md
index 6ec3654bc62c0..0f2b9455d7723 100644
--- a/mlir/docs/DefiningDialects.md
+++ b/mlir/docs/DefiningDialects/_index.md
@@ -1,20 +1,20 @@
# 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
diff erent 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
@@ -39,7 +39,7 @@ the Dialect class in a
diff erent `.td` file from the attributes, operations, typ
and other sub-components of the dialect to establish a proper layering between
the various
diff erent 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
@@ -170,7 +170,7 @@ and a constant operation should be generated. `hasConstantMaterializer` is used
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:
@@ -196,7 +196,7 @@ 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
@@ -270,7 +270,7 @@ 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
@@ -286,7 +286,7 @@ parser and printer of its Attributes and Types it should set these to `0` as nec
### 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
@@ -299,7 +299,7 @@ the `getCanonicalizationPatterns` method on the dialect, which has the form:
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
diff --git a/mlir/docs/Dialects/SPIR-V.md b/mlir/docs/Dialects/SPIR-V.md
index 2cdce1874c894..51ba3482a379a 100644
--- a/mlir/docs/Dialects/SPIR-V.md
+++ b/mlir/docs/Dialects/SPIR-V.md
@@ -1388,7 +1388,7 @@ dialect.
[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
@@ -1420,7 +1420,7 @@ dialect.
[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
diff --git a/mlir/docs/Dialects/_index.md b/mlir/docs/Dialects/_index.md
index da19ddcca7773..99ffcb96a84d2 100644
--- a/mlir/docs/Dialects/_index.md
+++ b/mlir/docs/Dialects/_index.md
@@ -3,4 +3,4 @@
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).
diff --git a/mlir/docs/Interfaces.md b/mlir/docs/Interfaces.md
index c66aabd59dabe..11e40cf30d216 100644
--- a/mlir/docs/Interfaces.md
+++ b/mlir/docs/Interfaces.md
@@ -342,7 +342,7 @@ void *TestDialect::getRegisteredInterfaceForOp(TypeID typeID,
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
diff --git a/mlir/docs/LangRef.md b/mlir/docs/LangRef.md
index 861eb13e4d0cd..07f804018c2aa 100644
--- a/mlir/docs/LangRef.md
+++ b/mlir/docs/LangRef.md
@@ -725,7 +725,7 @@ part of the syntax into an equivalent, but lighter weight form:
!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
@@ -837,7 +837,7 @@ part of the syntax into an equivalent, but lighter weight form:
#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
diff --git a/mlir/docs/PassManagement.md b/mlir/docs/PassManagement.md
index 9842cb9214461..498f8872d57ad 100644
--- a/mlir/docs/PassManagement.md
+++ b/mlir/docs/PassManagement.md
@@ -763,7 +763,7 @@ 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.
diff --git a/mlir/docs/Rationale/RationaleLinalgDialect.md b/mlir/docs/Rationale/RationaleLinalgDialect.md
index c0e351941b85c..237a8e3b6bda6 100644
--- a/mlir/docs/Rationale/RationaleLinalgDialect.md
+++ b/mlir/docs/Rationale/RationaleLinalgDialect.md
@@ -69,7 +69,7 @@ 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](
diff --git a/mlir/docs/Traits.md b/mlir/docs/Traits.md
index 4a6915c74d231..d14a207b9fb9f 100644
--- a/mlir/docs/Traits.md
+++ b/mlir/docs/Traits.md
@@ -40,7 +40,7 @@ Operation traits may also provide a `verifyTrait` or `verifyRegionTrait` hook
that is called when verifying the concrete operation. The
diff erence 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++
@@ -139,7 +139,7 @@ class MyType : public Type::TypeBase<MyType, ..., MyTrait, MyParametricTrait<10>
### 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
@@ -161,7 +161,7 @@ These can then be used in the `traits` list of an op definition:
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
diff --git a/mlir/docs/Tutorials/CreatingADialect.md b/mlir/docs/Tutorials/CreatingADialect.md
index 2926c3682ede3..af709fc46eff5 100644
--- a/mlir/docs/Tutorials/CreatingADialect.md
+++ b/mlir/docs/Tutorials/CreatingADialect.md
@@ -10,7 +10,7 @@ Public dialects are typically separated into at least 3 directories:
* 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
diff --git a/mlir/docs/Tutorials/QuickstartRewrites.md b/mlir/docs/Tutorials/QuickstartRewrites.md
index dd6bb4a831f0c..604148bd9c600 100644
--- a/mlir/docs/Tutorials/QuickstartRewrites.md
+++ b/mlir/docs/Tutorials/QuickstartRewrites.md
@@ -8,7 +8,7 @@ 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.
diff --git a/mlir/docs/Tutorials/Toy/Ch-2.md b/mlir/docs/Tutorials/Toy/Ch-2.md
index 29fd0f5fc5625..cd61bd5017526 100644
--- a/mlir/docs/Tutorials/Toy/Ch-2.md
+++ b/mlir/docs/Tutorials/Toy/Ch-2.md
@@ -351,7 +351,7 @@ void processConstantOp(mlir::Operation *operation) {
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
@@ -379,7 +379,7 @@ 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
@@ -405,8 +405,8 @@ 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:
@@ -431,7 +431,7 @@ ConstantOp::value()`.
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.
@@ -469,7 +469,7 @@ 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:
@@ -510,7 +510,7 @@ def ConstantOp : Toy_Op<"constant"> {
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.
@@ -583,7 +583,7 @@ 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
@@ -655,7 +655,7 @@ mlir::ParseResult PrintOp::parse(mlir::OpAsmParser &parser,
```
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
diff erent components:
* Directives
@@ -681,7 +681,7 @@ def PrintOp : Toy_Op<"print"> {
}
```
-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:
@@ -710,7 +710,7 @@ module {
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
diff --git a/mlir/docs/Tutorials/Toy/Ch-3.md b/mlir/docs/Tutorials/Toy/Ch-3.md
index 08e2d4036a70c..820308281c189 100644
--- a/mlir/docs/Tutorials/Toy/Ch-3.md
+++ b/mlir/docs/Tutorials/Toy/Ch-3.md
@@ -108,7 +108,7 @@ 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++
diff --git a/mlir/docs/Tutorials/Toy/Ch-5.md b/mlir/docs/Tutorials/Toy/Ch-5.md
index 8db592000054e..b9b83b8e1b9b8 100644
--- a/mlir/docs/Tutorials/Toy/Ch-5.md
+++ b/mlir/docs/Tutorials/Toy/Ch-5.md
@@ -201,7 +201,7 @@ many ways to go about this, each with their own tradeoffs:
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
diff --git a/mlir/docs/Tutorials/Toy/Ch-7.md b/mlir/docs/Tutorials/Toy/Ch-7.md
index 14eeb0eb18c6c..6148b92dadd85 100644
--- a/mlir/docs/Tutorials/Toy/Ch-7.md
+++ b/mlir/docs/Tutorials/Toy/Ch-7.md
@@ -513,4 +513,4 @@ module {
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).
More information about the Mlir-commits
mailing list