Index: mlir/docs/Bufferization.md =================================================================== --- mlir/docs/Bufferization.md +++ mlir/docs/Bufferization.md @@ -38,7 +38,7 @@ 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 Index: mlir/docs/Canonicalization.md =================================================================== --- mlir/docs/Canonicalization.md +++ mlir/docs/Canonicalization.md @@ -106,7 +106,7 @@ 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`. Index: mlir/docs/ConversionToLLVMDialect.md =================================================================== --- mlir/docs/ConversionToLLVMDialect.md +++ 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 @@ 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 @@ 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. Index: mlir/docs/DataLayout.md =================================================================== --- mlir/docs/DataLayout.md +++ mlir/docs/DataLayout.md @@ -97,7 +97,7 @@ ### 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 Index: mlir/docs/DebugActions.md =================================================================== --- mlir/docs/DebugActions.md +++ mlir/docs/DebugActions.md @@ -117,7 +117,7 @@ ## 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 Index: mlir/docs/DeclarativeRewrites.md =================================================================== --- mlir/docs/DeclarativeRewrites.md +++ mlir/docs/DeclarativeRewrites.md @@ -51,7 +51,7 @@ * 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 @@ `(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. Index: mlir/docs/Diagnostics.md =================================================================== --- mlir/docs/Diagnostics.md +++ mlir/docs/Diagnostics.md @@ -60,7 +60,7 @@ ``` 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++ Index: mlir/docs/Interfaces.md =================================================================== --- mlir/docs/Interfaces.md +++ mlir/docs/Interfaces.md @@ -252,7 +252,7 @@ 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 @@ - 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 @@ ##### 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. Index: mlir/docs/LLVMDialectMemRefConvention.md =================================================================== --- mlir/docs/LLVMDialectMemRefConvention.md +++ 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). Index: mlir/docs/LangRef.md =================================================================== --- mlir/docs/LangRef.md +++ mlir/docs/LangRef.md @@ -34,7 +34,7 @@ [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 @@ 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 @@ 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 @@ 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 @@ 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 @@ 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 @@ ### 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 @@ ### 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 Index: mlir/docs/OpDefinitions.md =================================================================== --- mlir/docs/OpDefinitions.md +++ mlir/docs/OpDefinitions.md @@ -341,7 +341,7 @@ 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 @@ * `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 @@ ##### 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 @@ `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 @@ [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 Index: mlir/docs/PassManagement.md =================================================================== --- mlir/docs/PassManagement.md +++ mlir/docs/PassManagement.md @@ -16,7 +16,7 @@ ## 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 @@ 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 @@ 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 @@ 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 @@ 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 Index: mlir/docs/PatternRewriter.md =================================================================== --- mlir/docs/PatternRewriter.md +++ mlir/docs/PatternRewriter.md @@ -310,4 +310,4 @@ 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. Index: mlir/docs/Quantization.md =================================================================== --- mlir/docs/Quantization.md +++ mlir/docs/Quantization.md @@ -173,10 +173,10 @@ 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. Index: mlir/docs/SPIRVToLLVMDialectConversion.md =================================================================== --- mlir/docs/SPIRVToLLVMDialectConversion.md +++ mlir/docs/SPIRVToLLVMDialectConversion.md @@ -55,7 +55,7 @@ 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 @@ 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 @@ ### `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 :-----------------------------------: | :-----------------------------------: Index: mlir/docs/SymbolsAndSymbolTables.md =================================================================== --- mlir/docs/SymbolsAndSymbolTables.md +++ 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 @@ 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 @@ ### Referencing a Symbol `Symbol`s are referenced symbolically by name via the -[`SymbolRefAttr`](LangRef.md#symbol-reference-attribute) attribute. A symbol +[`SymbolRefAttr`](Dialects/Builtin.md/#symbolrefattr) attribute. A symbol reference attribute contains a named reference to an operation that is nested within a symbol table. It may optionally contain a set of nested references that further resolve to a symbol nested within a different symbol table. When @@ -118,8 +118,8 @@ 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 @@ 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 Index: mlir/docs/Traits.md =================================================================== --- mlir/docs/Traits.md +++ mlir/docs/Traits.md @@ -211,7 +211,7 @@ 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. Index: mlir/include/mlir/IR/RegionKindInterface.td =================================================================== --- mlir/include/mlir/IR/RegionKindInterface.td +++ mlir/include/mlir/IR/RegionKindInterface.td @@ -23,7 +23,7 @@ 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"; Index: mlir/include/mlir/IR/SymbolInterfaces.td =================================================================== --- mlir/include/mlir/IR/SymbolInterfaces.td +++ mlir/include/mlir/IR/SymbolInterfaces.td @@ -24,7 +24,7 @@ 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";