[4/4][mlir][doc] Fix links and references in top level docs directory

[zero9178]

Summary

This if the fourth and final patch in a series of patches fixing markdown links and references inside the mlir documentation. This patch combined with the previous three should fix almost every broken link on mlir.llvm.org as far as I can tell.

This patch in particular addresses all Markdown files in the top level docs directory.
Other directories are part of other revisions:

• Dialects: https://reviews.llvm.org/D103011
• Rationale: https://reviews.llvm.org/D103013
• Tutorials: https://reviews.llvm.org/D103017

This patch in particular does not depend on any of them however.

[zero9178]

mlir/docs/LangRef.md

362

`#terminator-operations´. This reference is the only one that I did not find the correct title for. Has this section been deleted, renamed or moved? Or should this link just be deleted. There are two more occurrences of it in Traits.md as well.

mlir/docs/Bufferization.md

 nor does it do anything particularly intelligent with the placement of buffers
 w.r.t. control flow. Thus, a realistic compilation pipeline will usually consist
 of:
 
 1. Bufferization
 1. Buffer optimizations such as `buffer-hoisting`, `buffer-loop-hoisting`, and
    `promote-buffers-to-stack`, which do optimizations that are only exposed
    after bufferization.
-1. Finally, running the [buffer deallocation](BufferDeallocation.md) pass.
+1. Finally, running the [buffer deallocation](BufferDeallocationInternals.md) pass.
 
 After buffer deallocation has been completed, the program will be quite
 difficult to transform due to the presence of the deallocation ops. Thus, other
 optimizations such as linalg fusion on memrefs should be done before that stage.
 
 ## General structure of the bufferization process
 
 Bufferization consists of running multiple _partial_ bufferization passes,

mlir/docs/Canonicalization.md

 See the [quickstart guide](Tutorials/QuickstartRewrites.md) for information on
 defining operation rewrites.
 
 ### Canonicalizing with the `fold` method
 
 The `fold` mechanism is an intentionally limited, but powerful mechanism that
 allows for applying canonicalizations in many places throughout the compiler.
 For example, outside of the canonicalizer pass, `fold` is used within the
-[dialect conversion infrastructure](#DialectConversion.md) as a legalization
+[dialect conversion infrastructure](DialectConversion.md) as a legalization
 mechanism, and can be invoked directly anywhere with an `OpBuilder` via
 `OpBuilder::createOrFold`.
 
 `fold` has the restriction that no new operations may be created, and only the
 root operation may be replaced. It allows for updating an operation in-place, or
 returning a set of pre-existing values (or attributes) to replace the operation
 with. This ensures that the `fold` method is a truly "local" transformation, and
 can be invoked without the need for a pattern rewriter.

mlir/docs/ConversionToLLVMDialect.md

 # Conversion to the LLVM Dialect
 
 Conversion from several dialects that rely on
-[built-in types](LangRef.md#builtin-types) to the
+[built-in types](LangRef.md/#builtin-types) to the
 [LLVM Dialect](Dialects/LLVM.md) is expected to be performed through the
 [Dialect Conversion](DialectConversion.md) infrastructure.
 
 The conversion of types and that of the overall module structure is described in
 this document. Individual conversion passes provide a set of conversion patterns
 for ops in different dialects, such as `-convert-std-to-llvm` for ops in the
 [Standard dialect](Dialects/Standard.md) and `-convert-vector-to-llvm` in the
 [Vector dialect](Dialects/Vector.md). *Note that some conversions subsume the

 -   `f64` converts to `f64`
 -   `f80` converts to `f80`
 -   `f128` converts to `f128`
 
 ### Index Type
 
 Index type is converted to an LLVM dialect integer type with bitwidth equal to
 the bitwidth of the pointer size as specified by the
-[data layout](Dialects/LLVM.md#data-layout-and-triple) of the closest module.
+[data layout](Dialects/LLVM.md/#data-layout-and-triple) of the closest module.
 For example, on x86-64 CPUs it converts to `i64`. This behavior can be
 overridden by the type converter configuration, which is often exposed as a pass
 option by conversion passes.
 
 ### Vector Types
 
 LLVM IR only supports *one-dimensional* vectors, unlike MLIR where vectors can
 be multi-dimensional. Vector types cannot be nested in either IR. In the

 Memref types in MLIR have both static and dynamic information associated with
 them. In the general case, the dynamic information describes dynamic sizes in
 the logical indexing space and any symbols bound to the memref. This dynamic
 information must be present at runtime in the LLVM dialect equivalent type.
 
 In practice, the conversion supports two conventions:
 
 -   the default convention for memrefs in the
-    **[strided form](LangRef.md#strided-memref)**;
+    **[strided form](Dialects/Builtin.md/#strided-memref)**;
 -   a "bare pointer" conversion for statically-shaped memrefs with default
     layout.
 
 The choice between conventions is specified at type converter construction time
 and is often exposed as an option by conversion passes.
 
 Memrefs with arbitrary layouts are not supported. Instead, these layouts can be
 factored out of the type and used as part of index computation for operations

mlir/docs/DataLayout.md

 
 ## Custom Implementations
 
 Extensibility of the data layout modeling is provided through a set of MLIR
 [Interfaces](Interfaces.md).
 
 ### Data Layout Specifications
 
-Data layout specification is an [attribute](LangRef.md#attributes) that is
+Data layout specification is an [attribute](LangRef.md/#attributes) that is
 conceptually a collection of key-value pairs called data layout specification
 _entries_. Data layout specification attributes implement the
 `DataLayoutSpecInterface`, described below. Each entry is itself an attribute
 that implements the `DataLayoutEntryInterface`. Entries have a key, either a
 `Type` or an `Identifier`, and a value. Keys are used to associate entries with
 specific types or dialects: when handling a data layout properties request, a
 type or a dialect can only see the specification entries relevant to them and
 must go through the supplied `DataLayout` object for any recursive query. This

mlir/docs/DebugActions.md

bool shouldApplyPattern(Operation *currentOp, const Pattern &currentPattern) {
   // `currentOp`.
   return manager.shouldExecute<ApplyPatternAction>(currentOp, currentPattern);
 }
 ```
 
 ## Debug Action Handler
 
 A debug action handler provides the internal implementation for the various
-action related queries within the [`DebugActionManager`](debug-action-manager).
+action related queries within the [`DebugActionManager`](#debug-action-manager).
 Action handlers allow for external entities to control and inject external
 information into the compiler. Handlers can be registered with the
 `DebugActionManager` using `registerActionHandler`. There are two types of
 handlers; action-specific handlers and generic handlers.
 
 ### Action Specific Handlers
 
 Action specific handlers handle a specific debug action type, with the

mlir/docs/DeclarativeRewrites.md

 Per the current implementation, DRR does not have good support for the following
 features:
 
 *   Matching and generating ops with regions.
 *   Matching and generating ops with block arguments.
 *   Matching multi-result ops in nested patterns.
 *   Matching and generating variadic operand/result ops in nested patterns.
 *   Packing and unpacking variadic operands/results during generation.
-*   [`NativeCodeCall`](#native-code-call-transforming-the-generated-op)
+*   [`NativeCodeCall`](#nativecodecall-transforming-the-generated-op)
     returning more than one results.
 
 ## Rule Definition
 
 The core construct for defining a rewrite rule is defined in
 [`OpBase.td`][OpBase] as
 
 ```tablegen
class Pat<
     dag benefitsAdded = (addBenefit 0)> :
   Pattern<sourcePattern, [resultPattern], additionalConstraints, benefitAdded>;
 ```
 
 Each pattern is specified as a TableGen `dag` object with the syntax of
 `(operator arg0, arg1, ...)`.
 
 `operator` is typically an MLIR op, but it can also be other
-[directives](#special-directives). `argN` is for matching (if used in source
+[directives](#rewrite-directives). `argN` is for matching (if used in source
 pattern) or generating (if used in result pattern) the `N`-th argument for
 `operator`. If the `operator` is some MLIR operation, it means the `N`-th
 argument as specified in the `arguments` list of the op's definition.
 Therefore, we say op argument specification in pattern is **position-based**:
 the position where they appear matters.
 
 `argN` can be a `dag` object itself, thus we can have nested `dag` tree to model
 the def-use relationship between ops.

mlir/docs/Diagnostics.md

 method returns an [InFlightDiagnostic](#inflight-diagnostic) that can be
 modified further.
 
 ```c++
 InFlightDiagnostic emit(Location loc, DiagnosticSeverity severity);
 ```
 
 Using the `DiagnosticEngine`, though, is generally not the preferred way to emit
-diagnostics in MLIR. [`operation`](LangRef.md#operations) provides utility
+diagnostics in MLIR. [`operation`](LangRef.md/#operations) provides utility
 methods for emitting diagnostics:
 
 ```c++
 // `emit` methods available in the mlir namespace.
 InFlightDiagnostic emitError/Remark/Warning(Location);
 
 // These methods use the location attached to the operation.
 InFlightDiagnostic Operation::emitError/Remark/Warning();

mlir/docs/Interfaces.md

 ```
 
 #### Utilizing the ODS Framework
 
 Note: Before reading this section, the reader should have some familiarity with
 the concepts described in the
 [`Operation Definition Specification`](OpDefinitions.md) documentation.
 
-As detailed above, [Interfaces](attribute-operation-type-interfaces) allow for
+As detailed above, [Interfaces](#attributeoperationtype-interfaces) allow for
 attributes, operations, and types to expose method calls without requiring that
 the caller know the specific derived type. The downside to this infrastructure,
 is that it requires a bit of boiler plate to connect all of the pieces together.
 MLIR provides a mechanism with which to defines interfaces declaratively in ODS,
 and have the C++ definitions auto-generated.
 
 As an example, using the ODS framework would allow for defining the example
 interface above as:

 ##### RegionKindInterfaces
 
 *   `RegionKindInterface` - Used to describe the abstract semantics of regions.
     -   `RegionKind getRegionKind(unsigned index)` - Return the kind of the
         region with the given index inside this operation.
         -   RegionKind::Graph - represents a graph region without control flow
             semantics
         -   RegionKind::SSACFG - represents an
-            [SSA-style control flow](LangRef.md#modeling-control-flow) region
+            [SSA-style control flow](LangRef.md/#control-flow-and-ssacfg-regions) region
             with basic blocks and reachability
     -   `hasSSADominance(unsigned index)` - Return true if the region with the
         given index inside this operation requires dominance.
 
 ##### SymbolInterfaces
 
 *   `SymbolOpInterface` - Used to represent
-    [`Symbol`](SymbolsAndSymbolTables.md#symbol) operations which reside
+    [`Symbol`](SymbolsAndSymbolTables.md/#symbol) operations which reside
     immediately within a region that defines a
-    [`SymbolTable`](SymbolsAndSymbolTables.md#symbol-table).
+    [`SymbolTable`](SymbolsAndSymbolTables.md/#symbol-table).
 
 *   `SymbolUserOpInterface` - Used to represent operations that reference
-    [`Symbol`](SymbolsAndSymbolTables.md#symbol) operations. This provides the
+    [`Symbol`](SymbolsAndSymbolTables.md/#symbol) operations. This provides the
     ability to perform safe and efficient verification of symbol uses, as well
     as additional functionality.

mlir/docs/LLVMDialectMemRefConvention.md

 # Built-in Function and MemRef Calling Convention
 
 This documents describes the calling convention implemented in the conversion of
-built-in [function operation](LangRef.md#functions), standard
-[`call`](Dialects/Standard.md#stdcall-callop) operations and the handling of
-[`memref`](LangRef.md#memref-type) type equivalents in the
+built-in [function operation](Dialects/Builtin.md/#func-mlirfuncop), standard
+[`call`](Dialects/Standard.md/#stdcall-callop) operations and the handling of
+[`memref`](Dialects/Builtin.md#memreftype) type equivalents in the
 [LLVM dialect](Dialects/LLVM.md). The conversion assumes the _default_
 convention was used when converting
 [built-in to the LLVM dialect types](ConversionToLLVMDialect.md).
 
 ## Function Result Packing
 
 In case of multi-result functions, the returned values are inserted into a
 structure-typed value before being returned and extracted from it at the call

mlir/docs/LangRef.md

 
 MLIR is fundamentally based on a graph-like data structure of nodes, called
 *Operations*, and edges, called *Values*. Each Value is the result of exactly
 one Operation or Block Argument, and has a *Value Type* defined by the [type
 system](#type-system).  [Operations](#operations) are contained in
 [Blocks](#blocks) and Blocks are contained in [Regions](#regions). Operations
 are also ordered within their containing block and Blocks are ordered in their
 containing region, although this order may or may not be semantically
-meaningful in a given [kind of region](Interfaces.md#regionkindinterfaces)).
+meaningful in a given [kind of region](Interfaces.md/#regionkindinterfaces)).
 Operations may also contain regions, enabling hierarchical structures to be
 represented.
 
 Operations can represent many different concepts, from higher-level concepts
 like function definitions, function calls, buffer allocations, view or slices
 of buffers, and process creation, to lower-level concepts like
 target-independent arithmetic, target-specific instructions, configuration
 registers, and logic gates. These different concepts are represented by
 different operations in MLIR and the set of operations usable in MLIR can be
 arbitrarily extended.
 
 MLIR also provides an extensible framework for transformations on operations,
 using familiar concepts of compiler [Passes](Passes.md). Enabling an arbitrary
 set of passes on an arbitrary set of operations results in a significant
 scaling challenge, since each transformation must potentially take into
 account the semantics of any operation. MLIR addresses this complexity by
 allowing operation semantics to be described abstractly using
 [Traits](Traits.md) and [Interfaces](Interfaces.md), enabling transformations
 to operate on operations more generically.  Traits often describe verification
 constraints on valid IR, enabling complex invariants to be captured and
 checked. (see [Op vs
-Operation](Tutorials/Toy/Ch-2/#op-vs-operation-using-mlir-operations))
+Operation](Tutorials/Toy/Ch-2.md/#op-vs-operation-using-mlir-operations))
 
 One obvious application of MLIR is to represent an
 [SSA-based](https://en.wikipedia.org/wiki/Static_single_assignment_form) IR,
 like the LLVM core IR, with appropriate choice of operation types to define
 Modules, Functions, Branches, Memory Allocation, and verification constraints to
 ensure the SSA Dominance property. MLIR includes a collection of dialects which
 defines just such structures. However, MLIR is intended to be general enough to
 represent other compiler-like data structures, such as Abstract Syntax Trees in

 region in which they are defined and cannot be accessed or referenced
 outside of that region. Argument identifiers in mapping functions are
 in scope for the mapping body. Particular operations may further limit
 which identifiers are in scope in their regions. For instance, the
 scope of values in a region with [SSA control flow
 semantics](#control-flow-and-ssacfg-regions) is constrained according
 to the standard definition of [SSA
 dominance](https://en.wikipedia.org/wiki/Dominator_\(graph_theory\)). Another
-example is the [IsolatedFromAbove trait](Traits.md#isolatedfromabove),
+example is the [IsolatedFromAbove trait](Traits.md/#isolatedfromabove),
 which restricts directly accessing values defined in containing
 regions.
 
 Function identifiers and mapping identifiers are associated with
-[Symbols](SymbolsAndSymbolTables) and have scoping rules dependent on
+[Symbols](SymbolsAndSymbolTables.md) and have scoping rules dependent on
 symbol attributes.
 
 ## Dialects
 
 Dialects are the mechanism by which to engage with and extend the MLIR
 ecosystem. They allow for defining new [operations](#operations), as well as
 [attributes](#attributes) and [types](#type-system). Each dialect is given a
 unique `namespace` that is prefixed to each defined attribute/operation/type.

 
 A *Block* is a list of operations. In [SSACFG
 regions](#control-flow-and-ssacfg-regions), each block represents a compiler
 [basic block](https://en.wikipedia.org/wiki/Basic_block) where instructions
 inside the block are executed in order and terminator operations implement
 control flow branches between basic blocks.
 
 A region with a single block may not include a [terminator
 operation](#terminator-operations). The enclosing op can opt-out of this
 requirement with the `NoTerminator` trait. The top-level `ModuleOp` is an
 example of such operation which defined this trait and whose block body does
 not have a terminator.
 
 Blocks in MLIR take a list of block arguments, notated in a function-like
 way. Block arguments are bound to values specified by the semantics of
 individual operations. Block arguments of the entry block of a region are also
 arguments to the region and the values bound to these arguments are determined

 ```
 
 **Context:** The "block argument" representation eliminates a number
 of special cases from the IR compared to traditional "PHI nodes are
 operations" SSA IRs (like LLVM). For example, the [parallel copy
 semantics](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.524.5461&rep=rep1&type=pdf)
 of SSA is immediately apparent, and function arguments are no longer a
 special case: they become arguments to the entry block [[more
-rationale](Rationale/Rationale.md#block-arguments-vs-phi-nodes)]. Blocks
+rationale](Rationale/Rationale.md/#block-arguments-vs-phi-nodes)]. Blocks
 are also a fundamental concept that cannot be represented by
 operations because values defined in an operation cannot be accessed
 outside the operation.
 
 ## Regions
 
 ### Definition
 
 A region is an ordered list of MLIR [Blocks](#blocks). The semantics within a
 region is not imposed by the IR. Instead, the containing operation defines the
 semantics of the regions it contains. MLIR currently defines two kinds of
 regions: [SSACFG regions](#control-flow-and-ssacfg-regions), which describe
 control flow between blocks, and [Graph regions](#graph-regions), which do not
 require control flow between block. The kinds of regions within an operation
 are described using the
-[RegionKindInterface](Interfaces.md#regionkindinterfaces).
+[RegionKindInterface](Interfaces.md/#regionkindinterfaces).
 
 Regions do not have a name or an address, only the blocks contained in a
 region do. Regions must be contained within operations and have no type or
 attributes. The first block in the region is a special block called the 'entry
 block'. The arguments to the entry block are also the arguments of the region
 itself. The entry block cannot be listed as a successor of any other
 block. The syntax for a region is as follows:
 

 Regions provide hierarchical encapsulation of programs: it is impossible to
 reference, i.e. branch to, a block which is not in the same region as the
 source of the reference, i.e. a terminator operation. Similarly, regions
 provides a natural scoping for value visibility: values defined in a region
 don't escape to the enclosing region, if any. By default, operations inside a
 region can reference values defined outside of the region whenever it would
 have been legal for operands of the enclosing operation to reference those
 values, but this can be restricted using traits, such as
-[OpTrait::IsolatedFromAbove](Traits.md#isolatedfromabove), or a custom
+[OpTrait::IsolatedFromAbove](Traits.md/#isolatedfromabove), or a custom
 verifier.
 
 Example:
 
 ```mlir
   "any_op"(%a) ({ // if %a is in-scope in the containing region...
    // then %a is in-scope here too.
     %new_value = "another_op"(%a) : (i64) -> (i64)
   }) : (i64) -> (i64)
 ```
 
 MLIR defines a generalized 'hierarchical dominance' concept that operates
 across hierarchy and defines whether a value is 'in scope' and can be used by
 a particular operation. Whether a value can be used by another operation in
 the same region is defined by the kind of region. A value defined in a region
 can be used by an operation which has a parent in the same region, if and only
 if the parent could use the value. A value defined by an argument to a region
 can always be used by any operation deeply contained in the region. A value
 defined in a region can never be used outside of the region.
 
 ### Control Flow and SSACFG Regions
 
 In MLIR, control flow semantics of a region is indicated by
-[RegionKind::SSACFG](Interfaces.md#regionkindinterfaces).  Informally, these
+[RegionKind::SSACFG](Interfaces.md/#regionkindinterfaces).  Informally, these
 regions support semantics where operations in a region 'execute
 sequentially'. Before an operation executes, its operands have well-defined
 values. After an operation executes, the operands have the same values and
 results also have well-defined values. After an operation executes, the next
 operation in the block executes until the operation is the terminator operation
 at the end of a block, in which case some other operation will execute. The
 determination of the next instruction to execute is the 'passing of control
 flow'.

 operation to define its semantics. Note that if an operation triggers
 asynchronous execution of the region, it is under the responsibility of the
 operation caller to wait for the region to be executed guaranteeing that any
 directly used values remain live.
 
 ### Graph Regions
 
 In MLIR, graph-like semantics in a region is indicated by
-[RegionKind::Graph](Interfaces.md#regionkindinterfaces). Graph regions are
+[RegionKind::Graph](Interfaces.md/#regionkindinterfaces). Graph regions are
 appropriate for concurrent semantics without control flow, or for modeling
 generic directed graph data structures. Graph regions are appropriate for
 representing cyclic relationships between coupled values where there is no
 fundamental order to the relationships. For instance, operations in a graph
 region may represent independent threads of control with values representing
 streams of data. As usual in MLIR, the particular semantics of a region is
 completely determined by its containing operation. Graph regions may only
 contain a single basic block (the entry block).

mlir/docs/OpDefinitions.md

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

 
 ### Run `mlir-tblgen` to see the generated content
 
 TableGen syntax sometimes can be obscure; reading the generated content can be a
 very helpful way to understand and debug issues. To build `mlir-tblgen`, run
 `cmake --build . --target mlir-tblgen` in your build directory and find the
 `mlir-tblgen` binary in the `bin/` subdirectory. All the supported generators
 can be found via `mlir-tblgen --help`. For example, `--gen-op-decls` and
-`--gen-op-defs` as explained in [Generated C++ code](#generated-c++-code).
+`--gen-op-defs` as explained in [Generated C++ code](#generated-c-code).
 
 To see the generated code, invoke `mlir-tblgen` with a specific generator by
 providing include paths via `-I`. For example,
 
 ```sh
 # To see op C++ class declaration
 mlir-tblgen --gen-op-decls -I /path/to/mlir/include /path/to/input/td/file
 # To see op C++ class definition
*   Reference implementation may be provided along with the op definition.
     TODO: document expectation if the dependent op's definition changes.
 
 [TableGen]: https://llvm.org/docs/TableGen/index.html
 [TableGenProgRef]: https://llvm.org/docs/TableGen/ProgRef.html
 [TableGenBackend]: https://llvm.org/docs/TableGen/BackEnds.html#introduction
 [OpBase]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/OpBase.td
 [OpDefinitionsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
 [EnumsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/EnumsGen.cpp
-[StringAttr]: LangRef.md#string-attribute
-[IntegerAttr]: LangRef.md#integer-attribute
+[StringAttr]: Dialects/Builtin.md/#stringattr
+[IntegerAttr]: Dialects/Builtin.md/#integertype
 [AttrClasses]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/Attributes.h

mlir/docs/PassManagement.md

 
 See [MLIR Rewrites](Tutorials/QuickstartRewrites.md) for a quick start on graph
 rewriting in MLIR. If a transformation involves pattern matching operation DAGs,
 this is a great place to start.
 
 ## Operation Pass
 
 In MLIR, the main unit of abstraction and transformation is an
-[operation](LangRef.md#operations). As such, the pass manager is designed to
+[operation](LangRef.md/#operations). As such, the pass manager is designed to
 work on instances of operations at different levels of nesting. The structure of
 the [pass manager](#pass-manager), and the concept of nesting, is detailed
 further below. All passes in MLIR derive from `OperationPass` and adhere to the
 following restrictions; any noncompliance will lead to problematic behavior in
 multithreaded and other advanced scenarios:
 
 *   Modify any state referenced or relied upon outside the current being
     operated on. This includes adding or removing operations from the parent

 
 ### OperationPass : Op-Agnostic
 
 An `op-agnostic` pass operates on the operation type of the pass manager that it
 is added to. This means that passes of this type may operate on several
 different operation types. Passes of this type are generally written generically
 using operation [interfaces](Interfaces.md) and [traits](Traits.md). Examples of
 this type of pass are
-[Common Sub-Expression Elimination](Passes.md#-cse-eliminate-common-sub-expressions)
-and [Inlining](Passes.md#-inline-inline-function-calls).
+[Common Sub-Expression Elimination](Passes.md/#-cse-eliminate-common-sub-expressions)
+and [Inlining](Passes.md/#-inline-inline-function-calls).
 
 To create an operation pass, a derived class must adhere to the following:
 
 *   Inherit from the CRTP class `OperationPass`.
 *   Override the virtual `void runOnOperation()` method.
 
 A simple pass may look like:
 

 
 ### OpPassManager
 
 An `OpPassManager` is essentially a collection of passes to execute on an
 operation of a specific type. This operation type must adhere to the following
 requirement:
 
 *   Must be registered and marked
-    [`IsolatedFromAbove`](Traits.md#isolatedfromabove).
+    [`IsolatedFromAbove`](Traits.md/#isolatedfromabove).
 
     *   Passes are expected to not modify operations at or above the current
         operation being processed. If the operation is not isolated, it may
         inadvertently modify or traverse the SSA use-list of an operation it is
         not supposed to.
 
 Passes can be added to a pass manager via `addPass`. The pass must either be an
 `op-specific` pass operating on the same operation type as `OpPassManager`, or
 an `op-agnostic` pass.
 
 An `OpPassManager` is generally created by explicitly nesting a pipeline within
 another existing `OpPassManager` via the `nest<>` method. This method takes the
 operation type that the nested pass manager will operate on. At the top-level, a
 `PassManager` acts as an `OpPassManager`. Nesting in this sense, corresponds to
 the [structural](Tutorials/UnderstandingTheIRStructure.md) nesting within
-[Regions](LangRef.md#regions) of the IR.
+[Regions](LangRef.md/#regions) of the IR.
 
 For example, the following `.mlir`:
 
 ```
 module {
   spv.module "Logical" "GLSL450" {
     func @foo() {
       ...
*   This improves multi-threading performance by reducing the number of jobs
     that need to be scheduled, as well as increasing the efficiency of each job.
     An entire function pipeline can be run on each function asynchronously.
 
 ## Dynamic Pass Pipelines
 
 In some situations it may be useful to run a pass pipeline within another pass,
 to allow configuring or filtering based on some invariants of the current
 operation being operated on. For example, the
-[Inliner Pass](Passes.md#-inline-inline-function-calls) may want to run
+[Inliner Pass](Passes.md/#-inline-inline-function-calls) may want to run
 intraprocedural simplification passes while it is inlining to produce a better
 cost model, and provide more optimal inlining. To enable this, passes may run an
 arbitrary `OpPassManager` on the current operation being operated on or any
 operation nested within the current operation via the `LogicalResult
 Pass::runPipeline(OpPassManager &, Operation *)` method. This method returns
 whether the dynamic pipeline succeeded or failed, similarly to the result of the
 top-level `PassManager::run` method. A simple example is shown below:
 

mlir/docs/PatternRewriter.md

 The driver is configurable and supports two modes: 1) you may opt-in to a
 "top-down" traversal, which seeds the worklist with each operation top down and
 in a pre-order over the region tree.  This is generally more efficient in
 compile time.  2) the default is a "bottom up" traversal, which builds the
 initial worklist with a postorder traversal of the region tree.  This may
 match larger patterns with ambiguous pattern sets.
 
 Note: This driver is the one used by the [canonicalization](Canonicalization.md)
-[pass](Passes.md#-canonicalize-canonicalize-operations) in MLIR.
+[pass](Passes.md/#-canonicalize-canonicalize-operations) in MLIR.

mlir/docs/Quantization.md

 MLIR:
 
 *   *Quantization* dialect containing:
 
     *   A family of [QuantizedTypes](#quantized-type) which represent the
         mapping between *expressed* values (typically of a floating point
         computer type) and *storage* values (typically of an integral computer
         type).
-    *   [Type conversion ops](#quantized-type-conversion-ops) for converting
+    *   [Type conversion ops](#quantized-type-conversion-operations) for converting
         between types based on a QuantizedType and its *expressed* and *storage*
         sub-types.
-    *   [Instrumentation ops](#instrumentation-and-constraint-ops) for assigning
+    *   [Instrumentation ops](#instrumentation-and-constraint-operations) for assigning
         instrumentation points within the computation where runtime statistics
         may help guide the quantization process.
 
 *   [Integration with simulated quantization at training time](#integration-with-simulated-quantization-at-training-time)
 
 *   [TFLite native quantization](#tflite-native-quantization)
 
     *   The TFLite op-set natively supports uniform-quantized variants.

mlir/docs/SPIRVToLLVMDialectConversion.md

 ### Array types
 
 SPIR-V distinguishes between array type and run-time array type, the length of
 which is not known at compile time. In LLVM, it is possible to index beyond the
 end of the array. Therefore, runtime array can be implemented as a zero length
 array type.
 
 Moreover, SPIR-V supports the notion of array stride. Currently only natural
-strides (based on [`VulkanLayoutUtils`](VulkanLayoutUtils)) are supported. They
+strides (based on [`VulkanLayoutUtils`][VulkanLayoutUtils]) are supported. They
 are also mapped to LLVM array.
 
 SPIR-V Dialect                        | LLVM Dialect
 :-----------------------------------: | :-----------------------------------:
 `!spv.array<<count> x <element-type>>`| `!llvm.array<<count> x <element-type>>`
 `!spv.rtarray< <element-type> >`      | `!llvm.array<0 x <element-type>>`
 
 ### Struct types
module {
   }
 }
 ```
 
 The SPIR-V to LLVM conversion does not involve modelling of workgroups.
 Hence, we say that only current invocation is in conversion's scope. This means
 that global variables with pointers of `Input`, `Output`, and `Private` storage
 classes are supported. Also, `StorageBuffer` storage class is allowed for
-executing [`mlir-spirv-cpu-runner`](#`mlir-spirv-cpu-runner`).
+executing [`mlir-spirv-cpu-runner`](#mlir-spirv-cpu-runner).
 
 Moreover, `bind` that specifies the descriptor set and the binding number and
 `built_in` that specifies SPIR-V `BuiltIn` decoration have no conversion into
 LLVM dialect.
 
 Currently `llvm.mlir.global`s are created with `private` linkage for `Private`
 storage class and `External` for other storage classes, based on SPIR-V spec:
 

 ## Function conversion and related ops
 
 This section describes the conversion of function-related operations from SPIR-V
 to LLVM dialect.
 
 ### `spv.func`
 This op declares or defines a SPIR-V function and it is converted to `llvm.func`.
 This conversion handles signature conversion, and function control attributes
-remapping to LLVM dialect function [`passthrough` attribute](Dialects/LLVM.md#Attribute-pass-through).
+remapping to LLVM dialect function [`passthrough` attribute](Dialects/LLVM.md/#attribute-pass-through).
 
-The following mapping is used to map [SPIR-V function control](SPIRVFunctionAttributes) to
-[LLVM function attributes](LLVMFunctionAttributes):
+The following mapping is used to map [SPIR-V function control][SPIRVFunctionAttributes] to
+[LLVM function attributes][LLVMFunctionAttributes]:
 
 SPIR-V Function Control Attributes    | LLVM Function Attributes
 :-----------------------------------: | :-----------------------------------:
 None                                  | No function attributes passed
 Inline                                | `alwaysinline`
 DontInline                            | `noinline`
 Pure                                  | `readonly`
 Const                                 | `readnone`

mlir/docs/SymbolsAndSymbolTables.md

 # Symbols and Symbol Tables
 
 [TOC]
 
-With [Regions](LangRef.md#regions), the multi-level aspect of MLIR is structural
+With [Regions](LangRef.md/#regions), the multi-level aspect of MLIR is structural
 in the IR. A lot of infrastructure within the compiler is built around this
 nesting structure; including the processing of operations within the
-[pass manager](PassManagement.md#pass-manager). One advantage of the MLIR design
+[pass manager](PassManagement.md/#pass-manager). One advantage of the MLIR design
 is that it is able to process operations in parallel, utilizing multiple
 threads. This is possible due to a property of the IR known as
-[`IsolatedFromAbove`](Traits.md#isolatedfromabove).
+[`IsolatedFromAbove`](Traits.md/#isolatedfromabove).
 
 Without this property, any operation could affect or mutate the use-list of
 operations defined above. Making this thread-safe requires expensive locking in
 some of the core IR data structures, which becomes quite inefficient. To enable
 multi-threaded compilation without this locking, MLIR uses local pools for
 constant values as well as `Symbol` accesses for global values and variables.
 This document details the design of `Symbol`s, what they are and how they fit
 into the system.
 
 The `Symbol` infrastructure essentially provides a non-SSA mechanism in which to
 refer to an operation symbolically with a name. This allows for referring to
 operations defined above regions that were defined as `IsolatedFromAbove` in a
 safe way. It also allows for symbolically referencing operations define below
 other regions as well.
 
 ## Symbol
 
 A `Symbol` is a named operation that resides immediately within a region that
 defines a [`SymbolTable`](#symbol-table). The name of a symbol *must* be unique
 within the parent `SymbolTable`. This name is semantically similarly to an SSA
 result value, and may be referred to by other operations to provide a symbolic
 link, or use, to the symbol. An example of a `Symbol` operation is
-[`func`](LangRef.md#functions). `func` defines a symbol name, which is
+[`func`](Dialects/Builtin.md/#func-mlirfuncop). `func` defines a symbol name, which is
 [referred to](#referencing-a-symbol) by operations like
-[`std.call`](Dialects/Standard.md#call).
+[`std.call`](Dialects/Standard.md/#stdcall-callop).
 
 ### Defining or declaring a Symbol
 
 A `Symbol` operation should use the `SymbolOpInterface` interface to provide the
 necessary verification and accessors; it also supports
 operations, such as `module`, that conditionally define a symbol. `Symbol`s must
 have the following properties:
 

 defining a `SymbolTable`. A `SymbolTable` operation provides the container for
 the [`Symbol`](#symbol) operations. It verifies that all `Symbol` operations
 have a unique name, and provides facilities for looking up symbols by name.
 Operations defining a `SymbolTable` must use the `OpTrait::SymbolTable` trait.
 
 ### Referencing a Symbol
 
 `Symbol`s are referenced symbolically by name via the
-[`SymbolRefAttr`](LangRef.md#symbol-reference-attribute) attribute. A symbol
+[`SymbolRefAttr`](Dialects/Builtin.md/#symbolrefattr) attribute. A symbol
 reference attribute contains a named reference to an operation that is nested
 within a symbol table. It may optionally contain a set of nested references that
 further resolve to a symbol nested within a different symbol table. When
 resolving a nested reference, each non-leaf reference must refer to a symbol
 operation that is also a [symbol table](#symbol-table).
 
 Below is an example of how an operation can reference a symbol operation:
 

 // Our `foo.user` operation may refer to the nested symbol, by resolving through
 // the parent.
 "foo.user"() {uses = [@module_symbol::@nested_symbol]} : () -> ()
 ```
 
 Using an attribute, as opposed to an SSA value, has several benefits:
 
 *   References may appear in more places than the operand list; including
-    [nested attribute dictionaries](LangRef.md#dictionary-attribute),
-    [array attributes](LangRef.md#array-attribute), etc.
+    [nested attribute dictionaries](Dialects/Builtin.md/dictionaryattr),
+    [array attributes](Dialects/Builtin.md/#arrayattr), etc.
 
 *   Handling of SSA dominance remains unchanged.
 
     -   If we were to use SSA values, we would need to create some mechanism in
         which to opt-out of certain properties of it such as dominance.
         Attributes allow for referencing the operations irregardless of the
         order in which they were defined.
     -   Attributes simplify referencing operations within nested symbol tables,
         which are traditionally not visible outside of the parent region.
 
 The impact of this choice to use attributes as opposed to SSA values is that we
 now have two mechanisms with reference operations. This means that some dialects
 must either support both `SymbolRefs` and SSA value references, or provide
 operations that materialize SSA values from a symbol reference. Each has
 different trade offs depending on the situation. A function call may directly
 use a `SymbolRef` as the callee, whereas a reference to a global variable might
 use a materialization operation so that the variable can be used in other
 operations like `std.addi`.
-[`llvm.mlir.addressof`](Dialects/LLVM.md#llvmmliraddressof) is one example of
+[`llvm.mlir.addressof`](Dialects/LLVM.md/#llvmmliraddressof-mlirllvmaddressofop) is one example of
 such an operation.
 
 See the `LangRef` definition of the
-[`SymbolRefAttr`](LangRef.md#symbol-reference-attribute) for more information
+[`SymbolRefAttr`](Dialects/Builtin.md/#symbolrefattr) for more information
 about the structure of this attribute.
 
 Operations that reference a `Symbol` and want to perform verification and
 general mutation of the symbol should implement the `SymbolUserOpInterface` to
 ensure that symbol accesses are legal and efficient.
 
 ### Manipulating a Symbol
 

mlir/docs/Traits.md

 
 ### AutomaticAllocationScope
 
 *   `OpTrait::AutomaticAllocationScope` -- `AutomaticAllocationScope`
 
 This trait is carried by region holding operations that define a new scope for
 automatic allocation. Such allocations are automatically freed when control is
 transferred back from the regions of such operations. As an example, allocations
-performed by [`memref.alloca`](Dialects/MemRef.md#memrefalloca-allocaop) are
+performed by [`memref.alloca`](Dialects/MemRef.md/#memrefalloca-mlirmemrefallocaop) are
 automatically freed when control leaves the region of its closest surrounding op
 that has the trait AutomaticAllocationScope.
 
 ### Broadcastable
 
 *   `OpTrait::ResultsBroadcastableShape` -- `ResultsBroadcastableShape`
 
 This trait adds the property that the operation is known to have

mlir/include/mlir/IR/RegionKindInterface.td

 
 // OpInterface to query the properties of regions in an operation
 def RegionKindInterface : OpInterface<"RegionKindInterface"> {
   let description = [{
     Interface for operations to describe the abstract semantics of
     their regions. Currently, two kinds of regions are
     supported. RegionKind::Graph represents a graph region without
     control flow semantics. RegionKind::SSACFG represents an
-    [SSA-style control flow](LangRef.md#modeling-control-flow) region
+    [SSA-style control flow](../LangRef.md/#modeling-control-flow) region
     with basic blocks, sequential semantics, and reachability.
   }];
   let cppNamespace = "::mlir";
 
   let methods = [
     StaticInterfaceMethod<
       /*desc=*/[{
         Return the kind of the region with the given index inside this operation.

mlir/include/mlir/IR/SymbolInterfaces.td

 //===----------------------------------------------------------------------===//
 // SymbolOpInterface
 //===----------------------------------------------------------------------===//
 
 def Symbol : OpInterface<"SymbolOpInterface"> {
   let description = [{
     This interface describes an operation that may define a `Symbol`. A `Symbol`
     operation resides immediately within a region that defines a `SymbolTable`.
-    See [Symbols and SymbolTables](SymbolsAndSymbolTables.md) for more details
+    See [Symbols and SymbolTables](../SymbolsAndSymbolTables.md) for more details
     and constraints on `Symbol` operations.
   }];
   let cppNamespace = "::mlir";
 
   let methods = [
     InterfaceMethod<"Returns the name of this symbol.",
       "StringRef", "getName", (ins), [{
         // Don't rely on the trait implementation as optional symbol operations