diff --git a/mlir/docs/Canonicalization.md b/mlir/docs/Canonicalization.md --- a/mlir/docs/Canonicalization.md +++ b/mlir/docs/Canonicalization.md @@ -69,7 +69,7 @@ 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 @@ "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. @@ -202,7 +202,7 @@ 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 --- 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 @@ 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 rename from mlir/docs/AttributesAndTypes.md rename to mlir/docs/DefiningDialects/AttributesAndTypes.md --- 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 @@ 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 @@ 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 @@ 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 @@ -281,7 +281,7 @@ 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 @@ 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 rename from mlir/docs/OpDefinitions.md rename to mlir/docs/DefiningDialects/Operations.md --- a/mlir/docs/OpDefinitions.md +++ b/mlir/docs/DefiningDialects/Operations.md @@ -10,7 +10,7 @@ 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 @@ 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 @@ * `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 @@ ##### 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 @@ * 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 @@ [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 rename from mlir/docs/DefiningDialects.md rename to mlir/docs/DefiningDialects/_index.md --- 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 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 @@ -39,7 +39,7 @@ 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 @@ -170,7 +170,7 @@ 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 @@ ### 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 @@ ``` 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 @@ ### 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 @@ 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 --- a/mlir/docs/Dialects/SPIR-V.md +++ b/mlir/docs/Dialects/SPIR-V.md @@ -1388,7 +1388,7 @@ [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 @@ [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 --- 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 --- a/mlir/docs/Interfaces.md +++ b/mlir/docs/Interfaces.md @@ -342,7 +342,7 @@ 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 --- a/mlir/docs/LangRef.md +++ b/mlir/docs/LangRef.md @@ -725,7 +725,7 @@ !foo.something ``` -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 @@ #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 --- a/mlir/docs/PassManagement.md +++ b/mlir/docs/PassManagement.md @@ -763,7 +763,7 @@ ## 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 --- a/mlir/docs/Rationale/RationaleLinalgDialect.md +++ b/mlir/docs/Rationale/RationaleLinalgDialect.md @@ -69,7 +69,7 @@ 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 --- a/mlir/docs/Traits.md +++ b/mlir/docs/Traits.md @@ -40,7 +40,7 @@ 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++ @@ -139,7 +139,7 @@ ### 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 @@ 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 --- a/mlir/docs/Tutorials/CreatingADialect.md +++ b/mlir/docs/Tutorials/CreatingADialect.md @@ -10,7 +10,7 @@ * 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 --- a/mlir/docs/Tutorials/QuickstartRewrites.md +++ b/mlir/docs/Tutorials/QuickstartRewrites.md @@ -8,7 +8,7 @@ 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 --- a/mlir/docs/Tutorials/Toy/Ch-2.md +++ b/mlir/docs/Tutorials/Toy/Ch-2.md @@ -351,7 +351,7 @@ 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 @@ 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 @@ #### 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 @@ 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 @@ 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 @@ 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 @@ 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 @@ ``` 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 @@ -681,7 +681,7 @@ } ``` -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 @@ 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 --- a/mlir/docs/Tutorials/Toy/Ch-3.md +++ b/mlir/docs/Tutorials/Toy/Ch-3.md @@ -108,7 +108,7 @@ [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 --- a/mlir/docs/Tutorials/Toy/Ch-5.md +++ b/mlir/docs/Tutorials/Toy/Ch-5.md @@ -201,7 +201,7 @@ 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 --- a/mlir/docs/Tutorials/Toy/Ch-7.md +++ b/mlir/docs/Tutorials/Toy/Ch-7.md @@ -513,4 +513,4 @@ 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).