[Mlir-commits] [mlir] d35bd98 - [mlir][doc] Fix links and references in top level docs directory

Markus Böck llvmlistbot at llvm.org
Mon May 24 09:43:09 PDT 2021 

Author: Markus Böck
Date: 2021-05-24T18:43:00+02:00
New Revision: d35bd98651ec64a8c6c9e5b942d950a20ecdcb79

URL: https://github.com/llvm/llvm-project/commit/d35bd98651ec64a8c6c9e5b942d950a20ecdcb79
DIFF: https://github.com/llvm/llvm-project/commit/d35bd98651ec64a8c6c9e5b942d950a20ecdcb79.diff

LOG: [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

Added: 
    

Modified: 
    mlir/docs/Bufferization.md
    mlir/docs/Canonicalization.md
    mlir/docs/ConversionToLLVMDialect.md
    mlir/docs/DataLayout.md
    mlir/docs/DebugActions.md
    mlir/docs/DeclarativeRewrites.md
    mlir/docs/Diagnostics.md
    mlir/docs/Interfaces.md
    mlir/docs/LLVMDialectMemRefConvention.md
    mlir/docs/LangRef.md
    mlir/docs/OpDefinitions.md
    mlir/docs/PassManagement.md
    mlir/docs/PatternRewriter.md
    mlir/docs/Quantization.md
    mlir/docs/SPIRVToLLVMDialectConversion.md
    mlir/docs/SymbolsAndSymbolTables.md
    mlir/docs/Traits.md
    mlir/include/mlir/IR/RegionKindInterface.td
    mlir/include/mlir/IR/SymbolInterfaces.td

Removed: 
    


################################################################################
diff  --git a/mlir/docs/Bufferization.md b/mlir/docs/Bufferization.md
index eba93c7a6d348..ac2e06805cb22 100644
--- a/mlir/docs/Bufferization.md
+++ b/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
 
diff icult to transform due to the presence of the deallocation ops. Thus, other

diff  --git a/mlir/docs/Canonicalization.md b/mlir/docs/Canonicalization.md
index 143c9edfc976d..f2f6d7d751f5a 100644
--- a/mlir/docs/Canonicalization.md
+++ b/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`.
 

diff  --git a/mlir/docs/ConversionToLLVMDialect.md b/mlir/docs/ConversionToLLVMDialect.md
index 47fe018872b7f..29c5a2bc682d9 100644
--- a/mlir/docs/ConversionToLLVMDialect.md
+++ b/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.
 

diff  --git a/mlir/docs/DataLayout.md b/mlir/docs/DataLayout.md
index caa90cfda53a0..d12091a3b63bd 100644
--- a/mlir/docs/DataLayout.md
+++ b/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

diff  --git a/mlir/docs/DebugActions.md b/mlir/docs/DebugActions.md
index f0cdbf9835acc..585a6541c799b 100644
--- a/mlir/docs/DebugActions.md
+++ b/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

diff  --git a/mlir/docs/DeclarativeRewrites.md b/mlir/docs/DeclarativeRewrites.md
index b5ae3e83aaad7..27ae161978c8a 100644
--- a/mlir/docs/DeclarativeRewrites.md
+++ b/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.

diff  --git a/mlir/docs/Diagnostics.md b/mlir/docs/Diagnostics.md
index 6300dd3dc06c3..ae18844047c36 100644
--- a/mlir/docs/Diagnostics.md
+++ b/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++

diff  --git a/mlir/docs/Interfaces.md b/mlir/docs/Interfaces.md
index 927e1d89a1f5f..b444f65f81482 100644
--- a/mlir/docs/Interfaces.md
+++ b/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,7 +554,7 @@ 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.
@@ -562,11 +562,11 @@ interface section goes as follows:
 ##### 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.

diff  --git a/mlir/docs/LLVMDialectMemRefConvention.md b/mlir/docs/LLVMDialectMemRefConvention.md
index 8bcf704b28b74..29c7bb3faf51c 100644
--- a/mlir/docs/LLVMDialectMemRefConvention.md
+++ b/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).

diff  --git a/mlir/docs/LangRef.md b/mlir/docs/LangRef.md
index caaec6a209513..307baa64f9965 100644
--- a/mlir/docs/LangRef.md
+++ b/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

diff  --git a/mlir/docs/OpDefinitions.md b/mlir/docs/OpDefinitions.md
index 1ed9d80ebd646..0e85d32916c64 100644
--- a/mlir/docs/OpDefinitions.md
+++ b/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

diff  --git a/mlir/docs/PassManagement.md b/mlir/docs/PassManagement.md
index fcbf6365c1b9f..315f66cb6df8f 100644
--- a/mlir/docs/PassManagement.md
+++ b/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 
diff erent 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
 
diff erent 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

diff  --git a/mlir/docs/PatternRewriter.md b/mlir/docs/PatternRewriter.md
index 2e4d57e8f6e7a..59a07f49c49b0 100644
--- a/mlir/docs/PatternRewriter.md
+++ b/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.

diff  --git a/mlir/docs/Quantization.md b/mlir/docs/Quantization.md
index 4abc52493cabd..a230cc4948608 100644
--- a/mlir/docs/Quantization.md
+++ b/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.
 

diff  --git a/mlir/docs/SPIRVToLLVMDialectConversion.md b/mlir/docs/SPIRVToLLVMDialectConversion.md
index 718234330d01c..0b978f59d517e 100644
--- a/mlir/docs/SPIRVToLLVMDialectConversion.md
+++ b/mlir/docs/SPIRVToLLVMDialectConversion.md
@@ -55,7 +55,7 @@ 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
@@ -500,7 +500,7 @@ 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
@@ -780,10 +780,10 @@ 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
 :-----------------------------------: | :-----------------------------------:

diff  --git a/mlir/docs/SymbolsAndSymbolTables.md b/mlir/docs/SymbolsAndSymbolTables.md
index 90e0fab47c2c0..130d4953c6753 100644
--- a/mlir/docs/SymbolsAndSymbolTables.md
+++ b/mlir/docs/SymbolsAndSymbolTables.md
@@ -2,13 +2,13 @@
 
 [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
@@ -31,9 +31,9 @@ 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
 
@@ -67,7 +67,7 @@ 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 
diff erent symbol table. When
@@ -118,8 +118,8 @@ module @module_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.
 
@@ -138,11 +138,11 @@ 
diff erent 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

diff  --git a/mlir/docs/Traits.md b/mlir/docs/Traits.md
index add2c80f1d6d5..f8053c4cd5ea0 100644
--- a/mlir/docs/Traits.md
+++ b/mlir/docs/Traits.md
@@ -211,7 +211,7 @@ are nested inside of other operations that themselves have this trait.
 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.
 

diff  --git a/mlir/include/mlir/IR/RegionKindInterface.td b/mlir/include/mlir/IR/RegionKindInterface.td
index 59b235186455f..bef161c00def2 100644
--- a/mlir/include/mlir/IR/RegionKindInterface.td
+++ b/mlir/include/mlir/IR/RegionKindInterface.td
@@ -23,7 +23,7 @@ def RegionKindInterface : OpInterface<"RegionKindInterface"> {
     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";

diff  --git a/mlir/include/mlir/IR/SymbolInterfaces.td b/mlir/include/mlir/IR/SymbolInterfaces.td
index 0e8f5a13fe555..8bd6c25939cc0 100644
--- a/mlir/include/mlir/IR/SymbolInterfaces.td
+++ b/mlir/include/mlir/IR/SymbolInterfaces.td
@@ -24,7 +24,7 @@ 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";

More information about the Mlir-commits mailing list