[3/4][mlir][doc] Fix links and references in documentation of Tutorials

[zero9178]

Summary

This patch is the third in a series of patches fixing markdown links and references inside the mlir documentation. For the first see https://reviews.llvm.org/D103011. They are not dependent on each other however.

This patch addresses all broken references to other markdown files and sections inside the Tutorials folder.

[marbre]

LGTM! Just a NIT regarding [TensorType].

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

245

I know this about fixing the links, but shouldn't [TensorType] be changed to RankedTensorType?

[zero9178]

Changed links named "TensorType" to "RankedTensorType".

In particular there were 3 occurrences at:
Ch-2.md:245
Ch-5.md:18
Ch-5.md:100

@marbre could you double check whether those make sense in their respective contexts?

[rriddle]

Thanks!

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

22

This should still be tensor type.

101

These should be tensor type.

[zero9178]

Addressed review comments in final commit

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](../OpDefinitions.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
 FooOpsInterfaces.h.inc.
 
 The 'Transforms' directory contains rewrite rules for the dialect,
 typically described in TableGen file using the [DDR
-format](DeclarativeRewrites.md).
+format](../DeclarativeRewrites.md).
 
 Note that dialect names should not generally be suffixed with “Ops”,
 although some files pertaining only to the operations of a dialect (e.g.
 FooOps.cpp) might be.
 
 ## CMake best practices
 
 ### TableGen Targets

mlir/docs/Tutorials/DefiningAttributesAndTypes.md

 # Defining Dialect Attributes and Types
 
 This document is a quickstart to defining dialect specific extensions to the
-[attribute](LangRef.md#attributes) and [type](LangRef.md#type-system) systems in
+[attribute](../LangRef.md/#attributes) and [type](../LangRef.md/#type-system) systems in
 MLIR. The main part of this tutorial focuses on defining types, but the
 instructions are nearly identical for defining attributes.
 
-See [MLIR specification](LangRef.md) for more information about MLIR, the
+See [MLIR specification](../LangRef.md) for more information about MLIR, the
 structure of the IR, operations, etc.
 
 ## Types
 
 Types in MLIR (like attributes, locations, and many other things) are
 value-typed. This means that instances of `Type` are passed around by-value, as
 opposed to by-pointer or by-reference. The `Type` class in itself acts as a
 wrapper around an internal storage object that is uniqued within an instance of
 an `MLIRContext`.
 
 ### Defining the type class
 
 As described above, `Type` objects in MLIR are value-typed and rely on having an
 implicit internal storage object that holds the actual data for the type. When
 defining a new `Type` it isn't always necessary to define a new storage class.
 So before defining the derived `Type`, it's important to know which of the two
 classes of `Type` we are defining:
 
 Some types are _singleton_ in nature, meaning they have no parameters and only
-ever have one instance, like the [`index` type](../Dialects/Builtin.md#indextype).
+ever have one instance, like the [`index` type](../Dialects/Builtin.md/#indextype).
 
 Other types are _parametric_, and contain additional information that
 differentiates different instances of the same `Type`. For example the
-[`integer` type](../Dialects/Builtin.md#integertype) contains a bitwidth, with `i8` and
+[`integer` type](../Dialects/Builtin.md/#integertype) contains a bitwidth, with `i8` and
 `i16` representing different instances of
-[`integer` type](../Dialects/Builtin.md#integertype). _Parametric_ may also contain a
+[`integer` type](../Dialects/Builtin.md/#integertype). _Parametric_ may also contain a
 mutable component, which can be used, for example, to construct self-referring
 recursive types. The mutable component _cannot_ be used to differentiate
 instances of a type class, so usually such types contain other parametric
 components that serve to identify them.
 
 #### Singleton types
 
 For singleton types, we can jump straight into defining the derived type class.
public:
   }
 };
 ```
 
 ### Registering types with a Dialect
 
 Once the dialect types have been defined, they must then be registered with a
 `Dialect`. This is done via a similar mechanism to
-[operations](LangRef.md#operations), with the `addTypes` method. The one
+[operations](../LangRef.md/#operations), with the `addTypes` method. The one
 distinct difference with operations, is that when a type is registered the
 definition of its storage class must be visible.
 
 ```c++
 struct MyDialect : public Dialect {
   MyDialect(MLIRContext *context) : Dialect(/*name=*/"mydialect", context) {
     /// Add these defined types to the dialect.
     addTypes<SimpleType, ComplexType, RecursiveType>();
public:
 
   /// Print an instance of a type registered to the dialect.
   void printType(Type type, DialectAsmPrinter &printer) const override;
 };
 ```
 
 These methods take an instance of a high-level parser or printer that allows for
 easily implementing the necessary functionality. As described in the
-[MLIR language reference](../../LangRef.md#dialect-types), dialect types are
+[MLIR language reference](../LangRef.md/#dialect-types), dialect types are
 generally represented as: `! dialect-namespace < type-data >`, with a pretty
 form available under certain circumstances. The responsibility of our parser and
 printer is to provide the `type-data` bits.
 
 ### Traits
 
 Similarly to operations, `Type` classes may attach `Traits` that provide
 additional mixin methods and other data. `Trait` classes may be specified via

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
+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
-[Declarative Rewrite Rule](DeclarativeRewrites.md) for the detailed explanation
+[Table-driven Operation Definition](../OpDefinitions.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
 modeling tool to specify the ops and the C++ code to interact with these

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

 
 ## Interfacing with MLIR
 
 [Language Reference](../../LangRef.md)
 
 MLIR is designed to be a completely extensible infrastructure; there is no
 closed set of attributes (think: constant metadata), operations, or types. MLIR
 supports this extensibility with the concept of
-[Dialects](../../LangRef.md#dialects). Dialects provide a grouping mechanism for
+[Dialects](../../LangRef.md/#dialects). Dialects provide a grouping mechanism for
 abstraction under a unique `namespace`.
 
-In MLIR, [`Operations`](../../LangRef.md#operations) are the core unit of
+In MLIR, [`Operations`](../../LangRef.md/#operations) are the core unit of
 abstraction and computation, similar in many ways to LLVM instructions.
 Operations can have application-specific semantics and can be used to represent
 all of the core IR structures in LLVM: instructions, globals (like functions),
 modules, etc.
 
 Here is the MLIR assembly for the Toy `transpose` operations:
 
 ```mlir
 %t_tensor = "toy.transpose"(%tensor) {inplace = true} : (tensor<2x3xf64>) -> tensor<3x2xf64> loc("example/file/path":12:1)
 ```
 
 Let's break down the anatomy of this MLIR operation:
 
 -   `%t_tensor`
 
     *   The name given to the result defined by this operation (which includes
-        [a prefixed sigil to avoid collisions](../../LangRef.md#identifiers-and-keywords)).
+        [a prefixed sigil to avoid collisions](../../LangRef.md/#identifiers-and-keywords)).
         An operation may define zero or more results (in the context of Toy, we
         will limit ourselves to single-result operations), which are SSA values.
         The name is used during parsing but is not persistent (e.g., it is not
         tracked in the in-memory representation of the SSA value).
 
 -   `"toy.transpose"`
 
     *   The name of the operation. It is expected to be a unique string, with

 
 Shown here is the general form of an operation. As described above,
 the set of operations in MLIR is extensible. Operations are modeled
 using a small set of concepts, enabling operations to be reasoned
 about and manipulated generically. These concepts are:
 
 -   A name for the operation.
 -   A list of SSA operand values.
--   A list of [attributes](../../LangRef.md#attributes).
--   A list of [types](../../LangRef.md#type-system) for result values.
--   A [source location](../../Diagnostics.md#source-locations) for debugging
+-   A list of [attributes](../../LangRef.md/#attributes).
+-   A list of [types](../../LangRef.md/#type-system) for result values.
+-   A [source location](../../Diagnostics.md/#source-locations) for debugging
     purposes.
--   A list of successors [blocks](../../LangRef.md#blocks) (for branches,
+-   A list of successors [blocks](../../LangRef.md/#blocks) (for branches,
     mostly).
--   A list of [regions](../../LangRef.md#regions) (for structural operations
+-   A list of [regions](../../LangRef.md/#regions) (for structural operations
     like functions).
 
 In MLIR, every operation has a mandatory source location associated with it.
 Contrary to LLVM, where debug info locations are metadata and can be dropped, in
 MLIR, the location is a core requirement, and APIs depend on and manipulate it.
 Dropping a location is thus an explicit choice which cannot happen by mistake.
 
 To provide an illustration: If a transformation replaces an operation by
 another, that new operation must still have a location attached. This makes it
 possible to track where that operation came from.
 
 It's worth noting that the mlir-opt tool - a tool for testing
 compiler passes - does not include locations in the output by default. The
 `-mlir-print-debuginfo` flag specifies to include locations. (Run `mlir-opt
 --help` for more options.)
 
 ### Opaque API
 
 MLIR is designed to allow all IR elements, such as attributes, operations, and
 types, to be customized. At the same time, IR elements can always be reduced to
 the above fundamental concepts. This allows MLIR to parse, represent, and
-[round-trip](../../../getting_started/Glossary.md#round-trip) IR for *any*
+[round-trip](../../../getting_started/Glossary.md/#round-trip) IR for *any*
 operation. For example, we could place our Toy operation from above into an
 `.mlir` file and round-trip through *mlir-opt* without registering any dialect:
 
 ```mlir
 func @toy_func(%tensor: tensor<2x3xf64>) -> tensor<3x2xf64> {
   %t_tensor = "toy.transpose"(%tensor) { inplace = true } : (tensor<2x3xf64>) -> tensor<3x2xf64>
   return %t_tensor : tensor<3x2xf64>
 }

 hook into. As an example, let's walk through the creation of a `toy.constant`
 operation. This operation will represent a constant value in the Toy language.
 
 ```mlir
  %4 = "toy.constant"() {value = dense<1.0> : tensor<2x3xf64>} : () -> tensor<2x3xf64>
 ```
 
 This operation takes zero operands, a
-[dense elements](../../LangRef.md#dense-elements-attribute) attribute named
+[dense elements](../../Dialects/Builtin.md/#denseintorfpelementsattr) attribute named
 `value` to represent the constant value, and returns a single result of
-[TensorType](../../LangRef.md#tensor-type). An operation class inherits from the
+[TensorType](../../Dialects/Builtin.md/#rankedtensortype). An operation class inherits from the
 [CRTP](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern)
 `mlir::Op` class which also takes some optional [*traits*](../../Traits.md) to
 customize its behavior. `Traits` are a mechanism with which we can inject
 additional behavior into an Operation, such as additional accessors,
 verification, and more. Let's look below at a possible definition for the
 constant operation that we have described above:
 
 ```c++
class Toy_Op<string mnemonic, list<OpTrait> 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](../../OpDefinitions.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](../../OpDefinitions.md/#operation-arguments) and
+[outputs](../../OpDefinitions.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`](../../OpDefinitions.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`](../../OpDefinitions.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`](../../OpDefinitions.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 {
   } 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](../../OpDefinitions.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
static mlir::ParseResult parsePrintOp(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](../../OpDefinitions.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](../../OpDefinitions.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 {
   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)

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](../../OpDefinitions.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-4.md

 complexity that we want. Disregarding cost modeling, the pure structural
 transformation is already complex to implement from scratch. Thankfully, MLIR
 provides a generic inliner algorithm that dialects can plug into. All we need to
 do in Toy is to provide the [interfaces](../../Interfaces.md) for the inliner to
 hook into.
 
 The first thing we need to do is to define the constraints on inlining
 operations in the Toy dialect. This information is provided through a
-[dialect interface](../../Interfaces.md#dialect-interfaces). This is essentially
+[dialect interface](../../Interfaces.md/#dialect-interfaces). This is essentially
 a class containing a set of virtual hooks which the dialect can override.
 In this case, the interface is `DialectInlinerInterface`.
 
 ```c++
 /// This class defines the interface for handling inlining with Toy operations.
 /// We simplify inherit from the base interface class and override
 /// the necessary methods.
 struct ToyInlinerInterface : public DialectInlinerInterface {

 ```c++
 void ToyDialect::initialize() {
   addInterfaces<ToyInlinerInterface>();
 }
 ```
 
 Next, we need to provide a way for the inliner to know that `toy.generic_call`
 represents a call to a function. MLIR provides an
-[operation interface](../../Interfaces.md#operation-interfaces) that can be used
+[operation interface](../../Interfaces.md/#attributeoperationtype-interfaces) that can be used
 to mark an operation as being "call-like". Unlike dialect interfaces, operation
 interfaces provide a more refined granularity of information that is specific
 and core to a single operation. The interface that we will be adding here is the
 `CallOpInterface`.
 
 To add this interface we just need to include the definition into our operation
 specification file (`Ops.td`):
 

 For shape inference, if we break down the problem to its core, we really just
 want operations to tell us the expected outputs given a set of statically known
 inputs. (We can definitely get more complex than that, but for our needs we can
 keep it simple.) Given that this property is core to a specific operation, we
 can define an operation interface that can be specified on operations that need
 to have their result shapes inferred.
 
 Similarly to operations, we can also
-[define operation interfaces](../../OpDefinitions.md#operation-interfaces) using
+[define operation interfaces](../../Interfaces.md/#attributeoperationtype-interfaces) using
 the operation definition specification (ODS) framework.
 
 The interface is defined by inheriting from `OpInterface`, which takes the name
 to be given to the generated C++ interface class as a template argument. For our
 purposes, we will simply name the generated class `ShapeInference`. We also
 provide a description for the interface.
 
 ```tablegen
 def ShapeInferenceOpInterface : OpInterface<"ShapeInference"> {
   let description = [{
     Interface to access a registered method to infer the return types for an
     operation that can be used during type inference.
   }];
 }
 ```
 
 Next, we define the interface methods that the operations will need to provide.
 An interface method is comprised of: a description; a C++ return type in string
 form; a method name in string form; and a few optional components, depending on
 the need. See the
-[ODS documentation](../../OpDefinitions.md#operation-interfaces) for more
+[ODS documentation](../../Interfaces.md/#attributeoperationtype-interfaces) for more
 information.
 
 ```tablegen
 def ShapeInferenceOpInterface : OpInterface<"ShapeInference"> {
   ...
 
   let methods = [
     InterfaceMethod<"Infer and set the output shape for the current operation.",

 /// Infer the output shape of the MulOp, this is required by the shape inference
 /// interface.
 void MulOp::inferShapes() { getResult().setType(getOperand(0).getType()); }
 ```
 
 At this point, each of the necessary Toy operations provide a mechanism by which
 to infer their output shapes. The ShapeInferencePass is a FunctionPass: it will
 run on each Function in isolation. MLIR also supports general
-[OperationPasses](../../PassManagement.md#operation-pass) that run on any isolated
+[OperationPasses](../../PassManagement.md/#operation-pass) that run on any isolated
 operation (i.e. other function-like operations), but here our module only
 contains functions, so there is no need to generalize to all operations.
 
 Implementing such a pass is done by creating a class inheriting from
 `mlir::FunctionPass` and overriding the `runOnFunction()` method.
 
 ```c++
 class ShapeInferencePass

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

 To make it more interesting, in this chapter we will consider that we want to
 reuse existing optimizations implemented in a dialect optimizing affine
 transformations: `Affine`. This dialect is tailored to the computation-heavy
 part of the program and is limited: it doesn't support representing our
 `toy.print` builtin, for instance, neither should it! Instead, we can target
 `Affine` for the computation heavy part of Toy, and in the
 [next chapter](Ch-6.md) directly target the `LLVM IR` dialect for lowering
 `print`. As part of this lowering, we will be lowering from the
-[TensorType](../../LangRef.md#tensor-type) that `Toy` operates on to the
-[MemRefType](../../LangRef.md#memref-type) that is indexed via an affine
+[TensorType](../../Dialects/Builtin.md/#rankedtensortypes) that `Toy` operates on to the
+[MemRefType](../../Dialects/Builtin.md/#memreftype) that is indexed via an affine
 loop-nest. Tensors represent an abstract value-typed sequence of data, meaning
 that they don't live in any memory. MemRefs, on the other hand, represent lower
 level buffer access, as they are concrete references to a region of memory.
 
 # Dialect Conversions
 
 MLIR has many different dialects, so it is important to have a unified framework
-for [converting](../../../getting_started/Glossary.md#conversion) between them. This is where the
+for [converting](../../../getting_started/Glossary.md/#conversion) between them. This is where the
 `DialectConversion` framework comes into play. This framework allows for
 transforming a set of *illegal* operations to a set of *legal* ones. To use this
 framework, we need to provide two things (and an optional third):
 
-*   A [Conversion Target](../../DialectConversion.md#conversion-target)
+*   A [Conversion Target](../../DialectConversion.md/#conversion-target)
 
     -   This is the formal specification of what operations or dialects are
         legal for the conversion. Operations that aren't legal will require
         rewrite patterns to perform
-        [legalization](../../../getting_started/Glossary.md#legalization).
+        [legalization](../../../getting_started/Glossary.md/#legalization).
 
 *   A set of
-    [Rewrite Patterns](../../DialectConversion.md#rewrite-pattern-specification)
+    [Rewrite Patterns](../../DialectConversion.md/#rewrite-pattern-specification)
 
     -   This is the set of [patterns](../QuickstartRewrites.md) used to
         convert *illegal* operations into a set of zero or more *legal* ones.
 
-*   Optionally, a [Type Converter](../../DialectConversion.md#type-conversion).
+*   Optionally, a [Type Converter](../../DialectConversion.md/#type-conversion).
 
     -   If provided, this is used to convert the types of block arguments. We
         won't be needing this for our conversion.
 
 ## Conversion Target
 
 For our purposes, we want to convert the compute-intensive `Toy` operations into
 a combination of operations from the `Affine`, `MemRef` and `Standard` dialects

 [RewritePatterns](../QuickstartRewrites.md) to perform the conversion logic.
 These patterns may be the `RewritePatterns` seen before or a new type of pattern
 specific to the conversion framework `ConversionPattern`. `ConversionPatterns`
 are different from traditional `RewritePatterns` in that they accept an
 additional `operands` parameter containing operands that have been
 remapped/replaced. This is used when dealing with type conversions, as the
 pattern will want to operate on values of the new type but match against the
 old. For our lowering, this invariant will be useful as it translates from the
-[TensorType](../../LangRef.md#tensor-type) currently being operated on to the
-[MemRefType](../../LangRef.md#memref-type). Let's look at a snippet of lowering
+[TensorType](../../Dialects/Builtin.md/#rankedtensortypes) currently being operated on to the
+[MemRefType](../../Dialects/Builtin.md/#memreftype). Let's look at a snippet of lowering
 the `toy.transpose` operation:
 
 ```c++
 /// Lower the `toy.transpose` operation to an affine loop nest.
 struct TransposeOpLowering : public mlir::ConversionPattern {
   TransposeOpLowering(mlir::MLIRContext *ctx)
       : mlir::ConversionPattern(TransposeOp::getOperationName(), 1, ctx) {}
 
   /// Match and rewrite the given `toy.transpose` operation, with the given

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

 
 For this lowering, we will again use the dialect conversion framework to perform
 the heavy lifting. However, this time, we will be performing a full conversion
 to the [LLVM dialect](../../Dialects/LLVM.md). Thankfully, we have already
 lowered all but one of the `toy` operations, with the last being `toy.print`.
 Before going over the conversion to LLVM, let's lower the `toy.print` operation.
 We will lower this operation to a non-affine loop nest that invokes `printf` for
 each element. Note that, because the dialect conversion framework supports
-[transitive lowering](../../../getting_started/Glossary.md#transitive-lowering), we don't need to
+[transitive lowering](../../../getting_started/Glossary.md/#transitive-lowering), we don't need to
 directly emit operations in the LLVM dialect. By transitive lowering, we mean
 that the conversion framework may apply multiple patterns to fully legalize an
 operation. In this example, we are generating a structured loop nest instead of
 the branch-form in the LLVM dialect. As long as we then have a lowering from the
 loop operations to LLVM, the lowering will still succeed.
 
 During lowering we can get, or build, the declaration for printf as so:
 

 
 ### Conversion Patterns
 
 Now that the conversion target has been defined, we need to provide the patterns
 used for lowering. At this point in the compilation process, we have a
 combination of `toy`, `affine`, and `std` operations. Luckily, the `std` and
 `affine` dialects already provide the set of patterns needed to transform them
 into LLVM dialect. These patterns allow for lowering the IR in multiple stages
-by relying on [transitive lowering](../../../getting_started/Glossary.md#transitive-lowering).
+by relying on [transitive lowering](../../../getting_started/Glossary.md/#transitive-lowering).
 
 ```c++
   mlir::RewritePatternSet patterns(&getContext());
   mlir::populateAffineToStdConversionPatterns(patterns, &getContext());
   mlir::populateLoopToStdConversionPatterns(patterns, &getContext());
   mlir::populateStdToLLVMConversionPatterns(typeConverter, patterns);
 
   // The only remaining operation, to lower from the `toy` dialect, is the

 ```shell
 $ echo 'def main() { print([[1, 2], [3, 4]]); }' | ./bin/toyc-ch6 -emit=jit
 1.000000 2.000000
 3.000000 4.000000
 ```
 
 You can also play with `-emit=mlir`, `-emit=mlir-affine`, `-emit=mlir-llvm`, and
 `-emit=llvm` to compare the various levels of IR involved. Also try options like
-[`--print-ir-after-all`](../../PassManagement.md#ir-printing) to track the
+[`--print-ir-after-all`](../../PassManagement.md/#ir-printing) to track the
 evolution of the IR throughout the pipeline.
 
 The example code used throughout this section can be found in 
 test/Examples/Toy/Ch6/llvm-lowering.mlir.
 
 So far, we have worked with primitive data types. In the
 [next chapter](Ch-7.md), we will add a composite `struct` type.

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

 element types. The name of the `struct` and its elements are only useful for the
 AST of our `toy` compiler, so we don't need to encode it in the MLIR
 representation.
 
 ### Defining the Type Class
 
 #### Defining the Type Class
 
-As mentioned in [chapter 2](Ch-2.md), [`Type`](../../LangRef.md#type-system)
+As mentioned in [chapter 2](Ch-2.md), [`Type`](../../LangRef.md/#type-system)
 objects in MLIR are value-typed and rely on having an internal storage object
 that holds the actual data for the type. The `Type` class in itself acts as a
 simple wrapper around an internal `TypeStorage` object that is uniqued within an
 instance of an `MLIRContext`. When constructing a `Type`, we are internally just
 constructing and uniquing an instance of a storage class.
 
 When defining a new `Type` that contains parametric data (e.g. the `struct`
 type, which requires additional information to hold the element types), we will
 need to provide a derived storage class. The `singleton` types that don't have
-any additional data (e.g. the [`index` type](../../Dialects/Builtin.md#indextype)) don't
+any additional data (e.g. the [`index` type](../../Dialects/Builtin.md/#indextype)) don't
 require a storage class and use the default `TypeStorage`.
 
 ##### Defining the Storage Class
 
 Type storage objects contain all of the data necessary to construct and unique a
 type instance. Derived storage classes must inherit from the base
 `mlir::TypeStorage` and provide a set of aliases and hooks that will be used by
 the `MLIRContext` for uniquing. Below is the definition of the storage instance
void printType(mlir::Type type,
                  mlir::DialectAsmPrinter &printer) const override;
 };
 ```
 
 These methods take an instance of a high-level parser or printer that allows for
 easily implementing the necessary functionality. Before going into the
 implementation, let's think about the syntax that we want for the `struct` type
 in the printed IR. As described in the
-[MLIR language reference](../../LangRef.md#dialect-types), dialect types are
+[MLIR language reference](../../LangRef.md/#dialect-types), dialect types are
 generally represented as: `! dialect-namespace < type-data >`, with a pretty
 form available under certain circumstances. The responsibility of our `Toy`
 parser and printer is to provide the `type-data` bits. We will define our
 `StructType` as having the following form:
 
 ```
   struct-type ::= `struct` `<` type (`,` type)* `>`
 ```

 #### Adding New `Toy` Operations
 
 In addition to the existing operations, we will be adding a few new operations
 that will provide more specific handling of `structs`.
 
 ##### `toy.struct_constant`
 
 This new operation materializes a constant value for a struct. In our current
-modeling, we just use an [array attribute](../../LangRef.md#array-attribute)
+modeling, we just use an [array attribute](../../Dialects/Builtin.md/#arrayattr)
 that contains a set of constant values for each of the `struct` elements.
 
 ```mlir
   %0 = toy.struct_constant [
     dense<[[1.0, 2.0, 3.0], [4.0, 5.0, 6.0]]> : tensor<2x3xf64>
   ] : !toy.struct<tensor<*xf64>>
 ```
 

mlir/docs/Tutorials/Toy/_index.md

 # Toy Tutorial
 
 This tutorial runs through the implementation of a basic toy language on top of
 MLIR. The goal of this tutorial is to introduce the concepts of MLIR; in
-particular, how [dialects](../../LangRef.md#dialects) can help easily support
+particular, how [dialects](../../LangRef.md/#dialects) can help easily support
 language specific constructs and transformations while still offering an easy
 path to lower to LLVM or other codegen infrastructure. This tutorial is based on
 the model of the
 [LLVM Kaleidoscope Tutorial](https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/index.html).
 
 Another good source of introduction is the online [recording](https://www.youtube.com/watch?v=Y4SvqTtOIDk)
 from the 2020 LLVM Dev Conference ([slides](https://llvm.org/devmtg/2020-09/slides/MLIR_Tutorial.pdf)).
 
 This tutorial assumes you have cloned and built MLIR; if you have not yet done
 so, see
-[Getting started with MLIR](https://mlir.llvm.org/getting_started/).
+[Getting started with MLIR](../../../getting_started/).
 
 This tutorial is divided in the following chapters:
 
 -   [Chapter #1](Ch-1.md): Introduction to the Toy language and the definition
     of its AST.
 -   [Chapter #2](Ch-2.md): Traversing the AST to emit a dialect in MLIR,
     introducing base MLIR concepts. Here we show how to start attaching
     semantics to our custom operations in MLIR.

mlir/docs/Tutorials/UnderstandingTheIRStructure.md

 # Understanding the IR Structure
 
 The MLIR Language Reference describes the
-[High Level Structure](../LangRef/#high-level-structure), this document
+[High Level Structure](../LangRef.md/#high-level-structure), this document
 illustrates this structure through examples, and introduces at the same time the
 C++ APIs involved in manipulating it.
 
-We will implement a [pass](../PassManagement/#operation-pass) that traverses any
+We will implement a [pass](../PassManagement.md/#operation-pass) that traverses any
 MLIR input and prints the entity inside the IR. A pass (or in general almost any
 piece of IR) is always rooted with an operation. Most of the time the top-level
 operation is a `ModuleOp`, the MLIR `PassManager` is actually limited to
 operation on a top-level `ModuleOp`. As such a pass starts with an operation,
 and so will our traversal:
 
 ```
   void runOnOperation() override {
if (result.wasInterrupted())
     // One alloc wasn't matching.
     ...
 ```
 
 ## Traversing the def-use chains
 
 Another relationship in the IR is the one that links a `Value` with its users.
 As defined in the
-[language reference](https://mlir.llvm.org/docs/LangRef/#high-level-structure),
+[language reference](../LangRef.md/#high-level-structure),
 each Value is either a `BlockArgument` or the result of exactly one `Operation`
 (an `Operation` can have multiple results, each of them is a separate `Value`).
 The users of a `Value` are `Operation`s, through their arguments: each
 `Operation` argument references a single `Value`.
 
 Here is a code sample that inspects the operands of an `Operation` and prints
 some information about them: