[1/4][mlir][doc] Fix links and references in documentation of Dialects

[zero9178]

Summary

This patch is the first in a series of patches fixing markdown links and references inside the mlir documentation. I chose to split it in a few reviews to be able to iterate quicker and to ease review.

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

One change that was also done was to insert '/' between the markdown files and section:
Example:
Builtin.md#integertype
was changed to:
Builtin.md/#integertype

After compilation, hugo then translates the later to jump directly to the integer type section, but not the former. Not inserting the slash would simply jump to just the Builtin page, instead of the to the integertype section. I therefore changed occurrences of the former version to the later as well.

Depends on https://reviews.llvm.org/D103013

[zero9178]

mlir/docs/Dialects/SPIR-V.md

1399

MlirFloatType seems to have been unused. Neither do I know which section it is supposed to map to as there is no one floating point type in Builtin. I therefore chose to remove it.

[ftynse]

mlir/docs/Dialects/Linalg.md

40

I see that this is prior-art-namea is indeed the anchor name produced by Hugo, but could we rather fix that instead of perpetuating such bad anchors? This one in particular is due to the source file having <a name=""></a> in the header for some reason - https://github.com/llvm/llvm-project/blame/main/mlir/docs/Rationale/RationaleLinalgDialect.md#L115 - I suppose the intention was to use manually-specified anchors, but it doesn't seem to play well with the generator.

[zero9178]

Addressed Review comments.

Used the name prior-art instead of the badly auto generated one.
Change to the title in RationaleLinalgDialect.md is part of https://reviews.llvm.org/D103013 which this differential now depends on.

[ftynse]

Thanks!

mlir/docs/Dialects/Affine.md

 # 'affine' Dialect
 
 This dialect provides a powerful abstraction for affine operations and analyses.
 
 [TOC]
 
 ## Polyhedral Structures
 
 MLIR uses techniques from polyhedral compilation to make dependence analysis and
 loop transformations efficient and reliable. This section introduces some of the
 core concepts that are used throughout the document.
 
 ### Dimensions and Symbols
 
 Dimensions and symbols are the two kinds of identifiers that can appear in the
-polyhedral structures, and are always of [`index`](Builtin.md#indextype)
+polyhedral structures, and are always of [`index`](Builtin.md/#indextype)
 type. Dimensions are declared in parentheses and symbols are declared in square
 brackets.
 
 Examples:
 
 ```mlir
 // A 2d to 3d affine mapping.
 // d0/d1 are dimensions, s0 is a symbol

 
 The affine dialect imposes certain restrictions on dimension and symbolic
 identifiers to enable powerful analysis and transformation. An SSA value's use
 can be bound to a symbolic identifier if that SSA value is either
 1. a region argument for an op with trait `AffineScope` (eg. `FuncOp`),
 2. a value defined at the top level of an `AffineScope` op (i.e., immediately
 enclosed by the latter),
 3. a value that dominates the `AffineScope` op enclosing the value's use,
-4. the result of a [`constant` operation](Standard.md#constant-operation),
+4. the result of a [`constant` operation](Standard.md/#stdconstant-constantop),
 5. the result of an [`affine.apply`
-operation](#affineapply-operation) that recursively takes as arguments any valid
+operation](#affineapply-affineapplyop) that recursively takes as arguments any valid
 symbolic identifiers, or
-6. the result of a [`dim` operation](Standard.md#dim-operation) on either a
+6. the result of a [`dim` operation](MemRef.md/#memrefdim-mlirmemrefdimop) on either a
 memref that is an argument to a `AffineScope` op or a memref where the
 corresponding dimension is either static or a dynamic one in turn bound to a
 valid symbol.
 *Note:* if the use of an SSA value is not contained in any op with the
 `AffineScope` trait, only the rules 4-6 can be applied.
 
 Note that as a result of rule (3) above, symbol validity is sensitive to the
 location of the SSA use.  Dimensions may be bound not only to anything that a
 symbol is bound to, but also to induction variables of enclosing
-[`affine.for`](#affinefor-operation) and
-[`affine.parallel`](#affineparallel-operation) operations, and the result of an
-[`affine.apply` operation](#affineapply-operation) (which recursively may use
+[`affine.for`](#affinefor-affineforop) and
+[`affine.parallel`](#affineparallel-affineparallelop) operations, and the result of an
+[`affine.apply` operation](#affineapply-affineapplyop) (which recursively may use
 other dimensions and symbols).
 
 ### Affine Expressions
 
 Syntax:
 
 ```
 affine-expr ::= `(` affine-expr `)`

 `ceildiv` is the ceiling function which maps the result of the division of its
 first argument by its second argument to the smallest integer greater than or
 equal to that result. `floordiv` is a function which maps the result of the
 division of its first argument by its second argument to the largest integer
 less than or equal to that result. `mod` is the modulo operation: since its
 second argument is always positive, its results are always positive in our
 usage. The `integer-literal` operand for ceildiv, floordiv, and mod is always
 expected to be positive. `bare-id` is an identifier which must have type
-[index](Builtin.md#indextype). The precedence of operations in an affine
+[index](Builtin.md/#indextype). The precedence of operations in an affine
 expression are ordered from highest to lowest in the order: (1)
 parenthesization, (2) negation, (3) modulo, multiplication, floordiv, and
 ceildiv, and (4) addition and subtraction. All of these operators associate from
 left to right.
 
 A _multidimensional affine expression_ is a comma separated list of
 one-dimensional affine expressions, with the entire list enclosed in
 parentheses.

 with one or more symbols in its specification are known as "symbolic affine
 maps", and those with no symbols as "non-symbolic affine maps".
 
 **Context:** Affine maps are mathematical functions that transform a list of
 dimension indices and symbols into a list of results, with affine expressions
 combining the indices and symbols. Affine maps distinguish between
 [indices and symbols](#dimensions-and-symbols) because indices are inputs to the
 affine map when the map is called (through an operation such as
-[affine.apply](#affineapply-operation)), whereas symbols are bound when
+[affine.apply](#affineapply-affineapplyop)), whereas symbols are bound when
 the map is established (e.g. when a memref is formed, establishing a
-memory [layout map](../LangRef.md#layout-map)).
+memory [layout map](Builtin.md/#layout-map)).
 
 Affine maps are used for various core structures in MLIR. The restrictions we
 impose on their form allows powerful analysis and transformation, while keeping
 the representation closed with respect to several operations of interest.
 
 #### Named affine mappings
 
 Syntax:

mlir/docs/Dialects/Builtin.md

 
 ## Attributes
 
 [include "Dialects/BuiltinAttributes.md"]
 
 ## Location Attributes
 
 A subset of the builtin attribute values correspond to
-[source locations](../Diagnostics.md#source-locations), that may be attached to
+[source locations](../Diagnostics.md/#source-locations), that may be attached to
 Operations.
 
 [include "Dialects/BuiltinLocationAttributes.md"]
 
 ## Operations
 
 [include "Dialects/BuiltinOps.md"]
 
 ## Types
 
 [include "Dialects/BuiltinTypes.md"]

mlir/docs/Dialects/LLVM.md

 ### Context-Level Values
 
 Some value kinds in LLVM IR, such as constants and undefs, are uniqued in
 context and used directly in relevant operations. MLIR does not support such
 values for thread-safety and concept parsimony reasons. Instead, regular values
 are produced by dedicated operations that have the corresponding semantics:
 [`llvm.mlir.constant`](#llvmmlirconstant-mlirllvmconstantop),
 [`llvm.mlir.undef`](#llvmmlirundef-mlirllvmundefop),
-[`llvm.mlir.null`](#llvmmlirnull-mlirnullop). Note how these operations are
+[`llvm.mlir.null`](#llvmmlirnull-mlirllvmnullop). Note how these operations are
 prefixed with `mlir.` to indicate that they don't belong to LLVM IR but are only
 necessary to model it in MLIR. The values produced by these operations are
 usable just like any other value.
 
 Examples:
 
 ```mlir
 // Create an undefined value of structure type with a 32-bit integer followed

 LLVM dialect uses built-in types whenever possible and defines a set of
 complementary types, which correspond to the LLVM IR types that cannot be
 directly represented with built-in types. Similarly to other MLIR context-owned
 objects, the creation and manipulation of LLVM dialect types is thread-safe.
 
 MLIR does not support module-scoped named type declarations, e.g. `%s = type
 {i32, i32}` in LLVM IR. Instead, types must be fully specified at each use,
 except for recursive types where only the first reference to a named type needs
-to be fully specified. MLIR [type aliases](LangRef.md#type-aliases) can be used
+to be fully specified. MLIR [type aliases](../LangRef.md/#type-aliases) can be used
 to achieve more compact syntax.
 
 The general syntax of LLVM dialect types is `!llvm.`, followed by a type kind
 identifier (e.g., `ptr` for pointer or `struct` for structure) and by an
 optional list of type parameters in angle brackets. The dialect follows MLIR
 style for types with nested angle brackets and keyword specifiers rather than
 using different bracket styles to differentiate types. Types inside the angle
 brackets may omit the `!llvm.` prefix for brevity: the parser first attempts to

mlir/docs/Dialects/Linalg.md

 1.  Vectorization: Rewrite in Vector Form.
 1.  Lower to Loops (Affine, Generic, and Parallel).
 1.  Lower to Library Calls or Special Instructions, Intrinsics or ISA.
 1.  Partially Lower to Iterations Over a Finer-Grained Linalg Op.
 
 ## High-Level Description of Linalg Ops<a name="linalg_ops"></a>
 
 Linalg takes at least some inspiration from all previously
-[listed prior art](#prior_art). The design enables the definition of
+[listed prior art](../Rationale/RationaleLinalgDialect.md/#prior-art). The design enables the definition of
 ***CustomOps*** with generic properties that enable
 [key transformations](#key_transformations), including lowering to scalar
 load/store and other operations or to external library calls and intrinsics.
 
 These ops can have ***either tensor or buffer*** as both input and output
 operands. Output tensors operands serve the purpose of providing a unifying
 abstraction and give a shape to the results. Output tensors can come in 2
 flavors and are always associated with a corresponding op result:

 In the grander scheme, the reliance on late LICM was deemed a necessary risk.
 
 #### Putting it Together<a name="summary"></a>
 
 As it stands, the six properties above define the semantics of a
 `linalg.generic` op. It is an open question whether all of these semantics are
 strictly necessary in practice and whether some should or could be derived
 automatically while still maintaining the
-[core guiding principles](#guiding_principles).
+[core guiding principles](../Rationale/RationaleLinalgDialect.md/#core-guiding-principlesa-nameguiding_principlesa).
 
 For the time being, we have settled on the combination of these properties
 because of empirical evidence building and working on multiple high-level
 compilers. As we lay those down and engage more with the community, we expect
 multiple rounds of discussions and design changes to the original architecture.
 
 ### Data Representation: Views<a name="views"></a>
 

mlir/docs/Dialects/MemRef.md

 each followed by its indices, size of the data transfer in terms of the number
 of elements (of the elemental type of the memref), a tag memref with its
 indices, and optionally two additional arguments corresponding to the stride (in
 terms of number of elements) and the number of elements to transfer per stride.
 The tag location is used by a dma_wait operation to check for completion. The
 indices of the source memref, destination memref, and the tag memref have the
 same restrictions as any load/store operation in an affine context (whenever DMA
 operations appear in an affine context). See
-[restrictions on dimensions and symbols](Affine.md#restrictions-on-dimensions-and-symbols)
+[restrictions on dimensions and symbols](Affine.md/#restrictions-on-dimensions-and-symbols)
 in affine contexts. This allows powerful static analysis and transformations in
 the presence of such DMAs including rescheduling, pipelining / overlap with
 computation, and checking for matching start/end operations. The source and
 destination memref need not be of the same dimensionality, but need to have the
 same elemental type.
 
 For example, a `dma_start` operation that transfers 32 vector elements from a
 memref `%src` at location `[%i, %j]` to memref `%dst` at `[%k, %l]` would be

mlir/docs/Dialects/SPIR-V.md

 [ArrayType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypeArray
 [ImageType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypeImage
 [PointerType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypePointer
 [RuntimeArrayType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypeRuntimeArray
 [SampledImageType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpTypeSampledImage
 [MlirDialectConversion]: ../DialectConversion.md
 [StructType]: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#Structure
 [SpirvTools]: https://github.com/KhronosGroup/SPIRV-Tools
-[Rationale]: ../Rationale/#block-arguments-vs-phi-nodes
+[Rationale]: ../Rationale/Rationale.md/#block-arguments-vs-phi-nodes
 [ODS]: ../OpDefinitions.md
 [GreedyPatternRewriter]: https://github.com/llvm/llvm-project/blob/main/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp
-[MlirDialectConversionTypeConversion]: ../DialectConversion.md#type-converter
-[MlirDialectConversionRewritePattern]: ../DialectConversion.md#conversion-patterns
-[MlirDialectConversionSignatureConversion]: ../DialectConversion.md#region-signature-conversion
+[MlirDialectConversionTypeConversion]: ../DialectConversion.md/#type-converter
+[MlirDialectConversionRewritePattern]: ../DialectConversion.md/#conversion-patterns
+[MlirDialectConversionSignatureConversion]: ../DialectConversion.md/#region-signature-conversion
 [MlirOpInterface]: ../Interfaces/#operation-interfaces
-[MlirIntegerType]: Builtin.md#integertype
-[MlirFloatType]: ../LangRef.md#floating-point-types
-[MlirVectorType]: ../LangRef.md#vector-type
-[MlirMemrefType]: ../LangRef.md#memref-type
-[MlirIndexType]: Builtin.md#indextype
-[MlirGpuDialect]: ../Dialects/GPU.md
-[MlirStandardDialect]: ../Dialects/Standard.md
+[MlirIntegerType]: Builtin.md/#integertype
+[MlirVectorType]: Builtin.md/#vectortype
+[MlirMemrefType]: Builtin.md/#memreftype
+[MlirIndexType]: Builtin.md/#indextype
+[MlirGpuDialect]: GPU.md
+[MlirStandardDialect]: Standard.md
 [MlirSpirvHeaders]: https://github.com/llvm/llvm-project/tree/main/mlir/include/mlir/Dialect/SPIRV
 [MlirSpirvLibs]: https://github.com/llvm/llvm-project/tree/main/mlir/lib/Dialect/SPIRV
 [MlirSpirvTests]: https://github.com/llvm/llvm-project/tree/main/mlir/test/Dialect/SPIRV
 [MlirSpirvUnittests]: https://github.com/llvm/llvm-project/tree/main/mlir/unittests/Dialect/SPIRV
 [MlirGpuToSpirvHeaders]: https://github.com/llvm/llvm-project/tree/main/mlir/include/mlir/Conversion/GPUToSPIRV
 [MlirGpuToSpirvLibs]: https://github.com/llvm/llvm-project/tree/main/mlir/lib/Conversion/GPUToSPIRV
 [MlirStdToSpirvHeaders]: https://github.com/llvm/llvm-project/tree/main/mlir/include/mlir/Conversion/StandardToSPIRV
 [MlirStdToSpirvLibs]: https://github.com/llvm/llvm-project/tree/main/mlir/lib/Conversion/StandardToSPIRV

mlir/include/mlir/Dialect/Affine/IR/AffineOps.td

let description = [{
     upper-bound ::= `min`? affine-map-attribute dim-and-symbol-use-list | shorthand-bound
     shorthand-bound ::= ssa-id | `-`? integer-literal
     ```
 
     The `affine.for` operation represents an affine loop nest. It has one region
     containing its body. This region must contain one block that terminates with
     [`affine.yield`](#affineyield-affineyieldop). *Note:* when
     `affine.for` is printed in custom format, the terminator is omitted. The
-    block has one argument of [`index`](../LangRef.md#index-type) type that
+    block has one argument of [`index`](Builtin.md/#indextype) type that
     represents the induction variable of the loop.
 
     The `affine.for` operation executes its body a number of times iterating
     from a lower bound to an upper bound by a stride. The stride, represented by
     `step`, is a positive constant integer which defaults to "1" if not present.
     The lower and upper bounds specify a half-open range: the range includes the
     lower bound but does not include the!upper bound.
 
def AffineYieldOp : Affine_Op<"yield", [NoSideEffect, Terminator, ReturnLike,
 
   let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?";
 }
 
 def AffineVectorLoadOp : AffineLoadOpBase<"vector_load"> {
   let summary = "affine vector load operation";
   let description = [{
     The "affine.vector_load" is the vector counterpart of
-    [affine.load](#affineload-operation). It reads a slice from a
-    [MemRef](../LangRef.md#memref-type), supplied as its first operand,
-    into a [vector](../LangRef.md#vector-type) of the same base elemental type.
+    [affine.load](#affineload-affineloadop). It reads a slice from a
+    [MemRef](Builtin.md/#memreftype), supplied as its first operand,
+    into a [vector](Builtin.md/#vectortype) of the same base elemental type.
     The index for each memref dimension is an affine expression of loop induction
     variables and symbols. These indices determine the start position of the read
     within the memref. The shape of the return vector type determines the shape of
     the slice read from the memref. This slice is contiguous along the respective
     dimensions of the shape. Strided vector loads will be supported in the future.
     An affine expression of loop IVs and symbols must be specified for each
     dimension of the memref. The keyword 'symbol' can be used to indicate SSA
     identifiers which are symbolic.
def AffineVectorLoadOp : AffineLoadOpBase<"vector_load"> {
   let hasCanonicalizer = 1;
 }
 
 def AffineVectorStoreOp : AffineStoreOpBase<"vector_store"> {
   let summary = "affine vector store operation";
   let description = [{
     The "affine.vector_store" is the vector counterpart of
     [affine.store](#affinestore-affinestoreop). It writes a
-    [vector](../LangRef.md#vector-type), supplied as its first operand,
-    into a slice within a [MemRef](../LangRef.md#memref-type) of the same base
+    [vector](Builtin.md/#vectortype), supplied as its first operand,
+    into a slice within a [MemRef](Builtin.md/#memreftype) of the same base
     elemental type, supplied as its second operand.
     The index for each memref dimension is an affine expression of loop
     induction variables and symbols. These indices determine the start position
     of the write within the memref. The shape of th input vector determines the
     shape of the slice written to the memref. This slice is contiguous along the
     respective dimensions of the shape. Strided vector stores will be supported
     in the future.
     An affine expression of loop IVs and symbols must be specified for each

mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td

 //===----------------------------------------------------------------------===//
 
 def MemRef_AllocaOp : AllocLikeOp<"alloca", AutomaticAllocationScopeResource> {
   let summary = "stack memory allocation operation";
   let description = [{
     The `alloca` operation allocates memory on the stack, to be automatically
     released when control transfers back from the region of its closest
     surrounding operation with an
-    [`AutomaticAllocationScope`](../Traits.md#automaticallocationscope) trait.
+    [`AutomaticAllocationScope`](../Traits.md/#automaticallocationscope) trait.
     The amount of memory allocated is specified by its memref and additional
     operands. For example:
 
     ```mlir
     %0 = memref.alloca() : memref<8x64xf32>
     ```
 
     The optional list of dimension operands are bound to the dynamic dimensions
let description = [{
     The `load` op reads an element from a memref specified by an index list. The
     output of load is a new value with the same type as the elements of the
     memref. The arity of indices is the rank of the memref (i.e., if the memref
     loaded from is of rank 3, then 3 indices are required for the load following
     the memref identifier).
 
     In an `affine.if` or `affine.for` body, the indices of a load are restricted
     to SSA values bound to surrounding loop induction variables,
-    [symbols](Affine.md#dimensions-and-symbols), results of a
-    [`constant` operation](#stdconstant-constantop), or the result of an
+    [symbols](Affine.md/#dimensions-and-symbols), results of a
+    [`constant` operation](Standard.md/#stdconstant-constantop), or the result of an
     `affine.apply` operation that can in turn take as arguments all of the
     aforementioned SSA values or the recursively result of such an
     `affine.apply` operation.
 
     Example:
 
     ```mlir
     %1 = affine.apply affine_map<(d0, d1) -> (3*d0)> (%i, %j)
     %2 = affine.apply affine_map<(d0, d1) -> (d1+1)> (%i, %j)
     %12 = memref.load %A[%1, %2] : memref<8x?xi32, #layout, memspace0>
 
     // Example of an indirect load (treated as non-affine)
     %3 = affine.apply affine_map<(d0) -> (2*d0 + 1)>(%12)
     %13 = memref.load %A[%3, %2] : memref<4x?xi32, #layout, memspace0>
     ```
 
     **Context:** The `load` and `store` operations are specifically crafted to
     fully resolve a reference to an element of a memref, and (in affine
     `affine.if` and `affine.for` operations) the compiler can follow use-def
-    chains (e.g. through [`affine.apply`](Affine.md#affineapply-affineapplyop)
+    chains (e.g. through [`affine.apply`](Affine.md/#affineapply-affineapplyop)
     operations) to precisely analyze references at compile-time using polyhedral
     techniques. This is possible because of the
-    [restrictions on dimensions and symbols](Affine.md#restrictions-on-dimensions-and-symbols)
+    [restrictions on dimensions and symbols](Affine.md/#restrictions-on-dimensions-and-symbols)
     in these contexts.
   }];
 
   let arguments = (ins Arg<AnyMemRef, "the reference to load from",
                            [MemRead]>:$memref,
                        Variadic<Index>:$indices);
   let results = (outs AnyType:$result);
 
def MemRef_StoreOp : MemRef_Op<"store",
   let summary = "store operation";
   let description = [{
     Store a value to a memref location given by indices. The value stored should
     have the same type as the elemental type of the memref. The number of
     arguments provided within brackets need to match the rank of the memref.
 
     In an affine context, the indices of a store are restricted to SSA values
     bound to surrounding loop induction variables,
-    [symbols](Affine.md#restrictions-on-dimensions-and-symbols), results of a
-    [`constant` operation](#stdconstant-constantop), or the result of an
-    [`affine.apply`](Affine.md#affineapply-affineapplyop) operation that can in
+    [symbols](Affine.md/#restrictions-on-dimensions-and-symbols), results of a
+    [`constant` operation](Standard.md/#stdconstant-constantop), or the result of an
+    [`affine.apply`](Affine.md/#affineapply-affineapplyop) operation that can in
     turn take as arguments all of the aforementioned SSA values or the
     recursively result of such an `affine.apply` operation.
 
     Example:
 
     ```mlir
     memref.store %100, %A[%1, 1023] : memref<4x?xf32, #layout, memspace0>
     ```
 
     **Context:** The `load` and `store` operations are specifically crafted to
     fully resolve a reference to an element of a memref, and (in polyhedral
     `affine.if` and `affine.for` operations) the compiler can follow use-def
-    chains (e.g. through [`affine.apply`](Affine.md#affineapply-affineapplyop)
+    chains (e.g. through [`affine.apply`](Affine.md/#affineapply-affineapplyop)
     operations) to precisely analyze references at compile-time using polyhedral
     techniques. This is possible because of the
-    [restrictions on dimensions and symbols](Affine.md#restrictions-on-dimensions-and-symbols)
+    [restrictions on dimensions and symbols](Affine.md/#restrictions-on-dimensions-and-symbols)
     in these contexts.
   }];
 
   let arguments = (ins AnyType:$value,
                        Arg<AnyMemRef, "the reference to store to",
                            [MemWrite]>:$memref,
                        Variadic<Index>:$indices);
 

mlir/include/mlir/IR/BuiltinAttributes.td

let description = [{
     Locations or extended attribute kinds.
 
     **Rationale:** Identifying accesses to global data is critical to
     enabling efficient multi-threaded compilation. Restricting global
     data access to occur through symbols and limiting the places that can
     legally hold a symbol reference simplifies reasoning about these data
     accesses.
 
-    See [`Symbols And SymbolTables`](SymbolsAndSymbolTables.md) for more
+    See [`Symbols And SymbolTables`](../SymbolsAndSymbolTables.md) for more
     information.
 
     Examples:
 
     ```mlir
     @flat_reference
     @parent_reference::@nested_reference
     ```

mlir/include/mlir/IR/BuiltinTypes.td

let description = [{
     %A_u = memref_cast %A : memref<16x32xf32> -> memref<*xf32>
     %B_u = memref_cast %B : memref<16x32x64xf32> -> memref<*xf32>
     // call same function with dynamic ranks
     call @helper(%A_u) : (memref<*xf32>)->()
     call @helper(%B_u) : (memref<*xf32>)->()
     ```
 
     The core syntax and representation of a layout specification is a
-    [semi-affine map](Dialects/Affine.md#semi-affine-maps). Additionally,
+    [semi-affine map](Affine.md/#semi-affine-maps). Additionally,
     syntactic sugar is supported to make certain layout specifications more
     intuitive to read. For the moment, a `memref` supports parsing a strided
     form which is converted to a semi-affine map automatically.
 
     The memory space of a memref is specified by a target-specific attribute.
     It might be an integer value, string, dictionary or custom dialect attribute.
     The empty memory space (attribute is None) is target specific.
 
let description = [{
 
     // Loads data from memref '%A' using a 2D index: (%i, %j)
     %v = load %A[%i, %j] : memref<16x32xf32, #imapA>
     ```
 
     ##### Index Map
 
     An index map is a one-to-one
-    [semi-affine map](Dialects/Affine.md#semi-affine-maps) that transforms a
+    [semi-affine map](Affine.md/#semi-affine-maps) that transforms a
     multidimensional index from one index space to another. For example, the
     following figure shows an index map which maps a 2-dimensional index from a
     2x2 index space to a 3x3 index space, using symbols `S0` and `S1` as
     offsets.
 
     ![Index Map Example](/includes/img/index-map.svg)
 
     The number of domain dimensions and range dimensions of an index map can be
     different, but must match the number of dimensions of the input and output
     index spaces on which the map operates. The index space is always
     non-negative and integral. In addition, an index map must specify the size
     of each of its range dimensions onto which it maps. Index map symbols must
     be listed in order with symbols for dynamic dimension sizes first, followed
     by other required symbols.
 
     ##### Layout Map
 
-    A layout map is a [semi-affine map](Dialects/Affine.md#semi-affine-maps)
+    A layout map is a [semi-affine map](Affine.md/#semi-affine-maps)
     which encodes logical to physical index space mapping, by mapping input
     dimensions to their ordering from most-major (slowest varying) to most-minor
     (fastest varying). Therefore, an identity layout map corresponds to a
     row-major layout. Identity layout maps do not contribute to the MemRef type
     identification and are discarded on construction. That is, a type with an
     explicit identity map is `memref<?x?xf32, (i,j)->(i,j)>` is strictly the
     same as the one without layout maps, `memref<?x?xf32>`.
 
let description = [{
     with zero or more index maps, and ending with a layout map. The composition
     must be conformant: the number of dimensions of the range of one map, must
     match the number of dimensions of the domain of the next map in the
     composition.
 
     The semi-affine map composition specified in the memref type, maps from
     accesses used to index the memref in load/store operations to other index
     spaces (i.e. logical to physical index mapping). Each of the
-    [semi-affine maps](Affine.md) and thus its composition is required
+    [semi-affine maps](Affine.md/#semi-affine-maps) and thus its composition is required
     to be one-to-one.
 
     The semi-affine map composition can be used in dependence analysis, memory
     access pattern analysis, and for performance optimizations like
     vectorization, copy elision and in-place updates. If an affine map
     composition is not specified for the memref, the identity affine map is
     assumed.
 
let description = [{
     dimension may be a static non-negative decimal constant or be dynamically
     determined (indicated by `?`).
 
     The runtime representation of the MLIR tensor type is intentionally
     abstracted - you cannot control layout or get a pointer to the data. For
     low level buffer access, MLIR has a [`memref` type](#memref-type). This
     abstracted runtime representation holds both the tensor data values as well
     as information about the (potentially dynamic) shape of the tensor. The
-    [`dim` operation](Dialects/Standard.md#dim-operation) returns the size of a
+    [`dim` operation](MemRef.md/#memrefdim-mlirmemrefdimop) returns the size of a
     dimension from a value of tensor type.
 
     The `encoding` attribute provides additional information on the tensor.
     An empty attribute denotes a straightforward tensor without any specific
     structure. But particular properties, like sparsity or other specific
     characteristics of the data of the tensor can be encoded through this
     attribute. The semantics are defined by a type and attribute interface
     and must be respected by all passes that operate on tensor types.
let description = [{
     tuple-type ::= `tuple` `<` (type ( `,` type)*)? `>`
     ```
 
     The value of `tuple` type represents a fixed-size collection of elements,
     where each element may be of a different type.
 
     **Rationale:** Though this type is first class in the type system, MLIR
     provides no standard operations for operating on `tuple` types
-    ([rationale](Rationale/Rationale.md#tuple-types)).
+    ([rationale](Rationale/Rationale.md/#tuple-types)).
 
     Examples:
 
     ```mlir
     // Empty tuple.
     tuple<>
 
     // Single element