maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

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

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 integertype section. I therefore changed occurrences of the former version to the later as well.

Differential Revision: https://reviews.llvm.org/D103011
This commit is contained in:
Markus Böck 2021-05-25 14:50:59 +02:00
parent 6054bfa813
commit 9b99336d5d
10 changed files with 49 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
mlir/docs/Dialects/Affine.md
View File

@ -13,7 +13,7 @@ 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.
@ -66,11 +66,11 @@ can be bound to a symbolic identifier if that SSA value is either
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.
@ -80,9 +80,9 @@ valid symbol.
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
@ -113,7 +113,7 @@ 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
@ -157,9 +157,9 @@ 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

2
mlir/docs/Dialects/Builtin.md
View File

@ -18,7 +18,7 @@ extensible by design, any potential additions are heavily scrutinized.
## 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"]

4
mlir/docs/Dialects/LLVM.md
View File

@ -105,7 +105,7 @@ 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.
@ -194,7 +194,7 @@ 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

4
mlir/docs/Dialects/Linalg.md
View File

@ -37,7 +37,7 @@ Linalg IR and that have influenced its design:
## 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.
@ -493,7 +493,7 @@ 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

2
mlir/docs/Dialects/MemRef.md
View File

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

21
mlir/docs/Dialects/SPIR-V.md
View File

@ -1388,20 +1388,19 @@ dialect.
[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

12
mlir/include/mlir/Dialect/Affine/IR/AffineOps.td
View File

@ -133,7 +133,7 @@ def AffineForOp : Affine_Op<"for",
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
@ -912,9 +912,9 @@ 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
@ -976,8 +976,8 @@ def AffineVectorStoreOp : AffineStoreOpBase<"vector_store"> {
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

20
mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td
View File

@ -165,7 +165,7 @@ def MemRef_AllocaOp : AllocLikeOp<"alloca", AutomaticAllocationScopeResource> {
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:
@ -553,8 +553,8 @@ def LoadOp : MemRef_Op<"load",
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.
@ -574,10 +574,10 @@ def LoadOp : MemRef_Op<"load",
**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.
}];
@ -826,9 +826,9 @@ def MemRef_StoreOp : MemRef_Op<"store",
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.
@ -841,10 +841,10 @@ def MemRef_StoreOp : MemRef_Op<"store",
**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.
}];

2
mlir/include/mlir/IR/BuiltinAttributes.td
View File

@ -856,7 +856,7 @@ def Builtin_SymbolRefAttr : Builtin_Attr<"SymbolRef"> {
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:

12
mlir/include/mlir/IR/BuiltinTypes.td
View File

@ -327,7 +327,7 @@ def Builtin_MemRef : Builtin_Type<"MemRef", "BaseMemRefType"> {
```
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.
@ -422,7 +422,7 @@ def Builtin_MemRef : Builtin_Type<"MemRef", "BaseMemRefType"> {
##### 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
@ -440,7 +440,7 @@ def Builtin_MemRef : Builtin_Type<"MemRef", "BaseMemRefType"> {
##### 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
@ -474,7 +474,7 @@ def Builtin_MemRef : Builtin_Type<"MemRef", "BaseMemRefType"> {
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
@ -650,7 +650,7 @@ def Builtin_RankedTensor : Builtin_Type<"RankedTensor", "TensorType"> {
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.
@ -730,7 +730,7 @@ def Builtin_Tuple : Builtin_Type<"Tuple"> {
**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: