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

This is the fourth and final patch in a series of patches fixing markdown links and references inside the mlir documentation. This patch combined with the other 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.

Differential Revision: https://reviews.llvm.org/D103032

mlir/docs/Bufferization.md

@@ -38,7 +38,7 @@ of:
 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

mlir/docs/Canonicalization.md

@@ -106,7 +106,7 @@ defining operation rewrites.
 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`.
 

mlir/docs/ConversionToLLVMDialect.md

@@ -1,7 +1,7 @@
 # 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.
 
@@ -36,7 +36,7 @@ following conversions are currently implemented:
 
 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.
@@ -63,7 +63,7 @@ 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.
 

mlir/docs/DataLayout.md

@@ -97,7 +97,7 @@ Extensibility of the data layout modeling is provided through a set of MLIR
 
 ### 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

mlir/docs/DebugActions.md

@@ -117,7 +117,7 @@ bool shouldApplyPattern(Operation *currentOp, const Pattern &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

mlir/docs/DeclarativeRewrites.md

@@ -51,7 +51,7 @@ features:
 *   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
@@ -90,7 +90,7 @@ 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.

mlir/docs/Diagnostics.md

@@ -60,7 +60,7 @@ 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++

mlir/docs/Interfaces.md

@@ -252,7 +252,7 @@ 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.
@@ -554,19 +554,19 @@ interface section goes as follows:
         -   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

@@ -1,9 +1,9 @@
 # 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).

mlir/docs/LangRef.md

@@ -34,7 +34,7 @@ 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.
 
@@ -56,7 +56,7 @@ allowing operation semantics to be described abstractly using
 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,
@@ -223,12 +223,12 @@ 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
@@ -411,7 +411,7 @@ 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.
@@ -427,7 +427,7 @@ 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
@@ -459,7 +459,7 @@ 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:
@@ -483,7 +483,7 @@ 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
@@ -569,7 +569,7 @@ 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

mlir/docs/OpDefinitions.md

@@ -341,7 +341,7 @@ currently only be specified as the last successor in the successor list.
 Traits are operation properties that affect syntax or semantics. MLIR C++ models
 various traits in the `mlir::OpTrait` namespace.
 
-Both operation traits, [interfaces](Interfaces.md#utilizing-the-ods-framework),
+Both operation traits, [interfaces](Interfaces.md/#utilizing-the-ods-framework),
 and constraints involving multiple operands/attributes/results are provided as
 the second template parameter to the `Op` class. They should be deriving from
 the `OpTrait` class. See [Constraints](#constraints) for more information.
@@ -605,7 +605,7 @@ The available directives are as follows:
 *   `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.
 
@@ -814,7 +814,7 @@ def ReturnOp : ... {
 
 ##### 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
@@ -1753,7 +1753,7 @@ 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,
@@ -1844,6 +1844,6 @@ requirements that were desirable:
 [OpBase]: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/OpBase.td
 [OpDefinitionsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
 [EnumsGen]: https://github.com/llvm/llvm-project/blob/main/mlir/tools/mlir-tblgen/EnumsGen.cpp
-[StringAttr]: 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

@@ -16,7 +16,7 @@ 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
@@ -98,8 +98,8 @@ 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:
 
@@ -298,7 +298,7 @@ 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
@@ -314,7 +314,7 @@ 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`:
 
@@ -393,7 +393,7 @@ program has been run through the passes. This provides several benefits:
 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

mlir/docs/PatternRewriter.md

@@ -310,4 +310,4 @@ 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

@@ -173,10 +173,10 @@ MLIR:
         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.