diff options
author | mlevesquedion <mlevesquedion@google.com> | 2024-02-17 13:51:36 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-02-17 13:51:36 -0800 |
commit | a90a09fa2e05c8841d145605e8d99020592dd809 (patch) | |
tree | 76516fe9e00f9441b4d18b830008af9d73ccc912 | |
parent | 3bef17eac607f3501e684088158d3265f4893807 (diff) |
[mlir][docs] Fix broken links to traits documentation (#82131)
It seems the `Traits.md` file was turned into `Traits/_index.md` in
https://reviews.llvm.org/D153291, causing links to `Traits.md` to no
longer work (instead, `Traits` needs to be used).
-rw-r--r-- | mlir/docs/DefiningDialects/AttributesAndTypes.md | 2 | ||||
-rw-r--r-- | mlir/docs/Interfaces.md | 8 | ||||
-rw-r--r-- | mlir/docs/LangRef.md | 6 | ||||
-rw-r--r-- | mlir/docs/PassManagement.md | 2 | ||||
-rw-r--r-- | mlir/docs/SymbolsAndSymbolTables.md | 2 | ||||
-rw-r--r-- | mlir/docs/Tutorials/Toy/Ch-2.md | 2 |
6 files changed, 11 insertions, 11 deletions
diff --git a/mlir/docs/DefiningDialects/AttributesAndTypes.md b/mlir/docs/DefiningDialects/AttributesAndTypes.md index 0302d274a653..950acb842022 100644 --- a/mlir/docs/DefiningDialects/AttributesAndTypes.md +++ b/mlir/docs/DefiningDialects/AttributesAndTypes.md @@ -305,7 +305,7 @@ MLIR includes several specialized classes for common situations: Similarly to operations, Attribute and Type classes may attach `Traits` that provide additional mixin methods and other data. `Trait`s may be attached via the trailing template argument, i.e. the `traits` list parameter in the example -above. See the main [`Trait`](../Traits.md) documentation for more information +above. See the main [`Trait`](../Traits) documentation for more information on defining and using traits. ### Interfaces diff --git a/mlir/docs/Interfaces.md b/mlir/docs/Interfaces.md index 343522c5a325..536e7613e509 100644 --- a/mlir/docs/Interfaces.md +++ b/mlir/docs/Interfaces.md @@ -132,7 +132,7 @@ methods that are overridden by the `Model` that is templated on the concrete entity type. It is important to note that these classes should be pure, and should not contain non-static data members or other mutable data. To attach an interface to an object, the base interface classes provide a -[`Trait`](Traits.md) class that can be appended to the trait list of that +[`Trait`](Traits) class that can be appended to the trait list of that object. ```c++ @@ -420,7 +420,7 @@ comprised of the following components: - A C++ code block containing additional verification applied to the operation that the interface is attached to. - The structure of this code block corresponds 1-1 with the structure of a - [`Trait::verifyTrait`](Traits.md) method. + [`Trait::verifyTrait`](Traits) method. ##### Interface Methods @@ -457,7 +457,7 @@ Interface methods are comprised of the following components: - This implementation is placed within the `Trait` class that is attached to the IR entity, and does not directly affect any of the interface classes. As such, this method has the same characteristics as any other - [`Trait`](Traits.md) method. + [`Trait`](Traits) method. - `ConcreteAttr`/`ConcreteOp`/`ConcreteType` is an implicitly defined `typename` that can be used to refer to the type of the derived IR entity currently being operated on. @@ -601,7 +601,7 @@ def MyInterface : OpInterface<"MyInterface"> { }; ``` - As detailed in [Traits](Traits.md), given that each operation implementing + As detailed in [Traits](Traits), given that each operation implementing this interface will also add the interface trait, the methods on this interface are inherited by the derived operation. This allows for injecting a default implementation of this method into each operation that diff --git a/mlir/docs/LangRef.md b/mlir/docs/LangRef.md index 52b0d8317eef..8efc88815b88 100644 --- a/mlir/docs/LangRef.md +++ b/mlir/docs/LangRef.md @@ -49,7 +49,7 @@ using familiar concepts of compiler [Passes](Passes.md). Enabling an arbitrary set of passes on an arbitrary set of operations results in a significant scaling challenge, since each transformation must potentially take into account the semantics of any operation. MLIR addresses this complexity by allowing operation -semantics to be described abstractly using [Traits](Traits.md) and +semantics to be described abstractly using [Traits](Traits) and [Interfaces](Interfaces.md), enabling transformations to operate on operations more generically. Traits often describe verification constraints on valid IR, enabling complex invariants to be captured and checked. (see @@ -234,7 +234,7 @@ their regions. For instance, the 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), +Another example is the [IsolatedFromAbove trait](Traits/#isolatedfromabove), which restricts directly accessing values defined in containing regions. Function identifiers and mapping identifiers are associated with @@ -478,7 +478,7 @@ 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/#isolatedfromabove), or a custom verifier. Example: diff --git a/mlir/docs/PassManagement.md b/mlir/docs/PassManagement.md index bec0a27ebd33..ff86bbfef7b0 100644 --- a/mlir/docs/PassManagement.md +++ b/mlir/docs/PassManagement.md @@ -362,7 +362,7 @@ specific operation, and executed on any viable operation type). Operation types anchor pass managers must adhere to the following requirement: * Must be registered and marked - [`IsolatedFromAbove`](Traits.md/#isolatedfromabove). + [`IsolatedFromAbove`](Traits/#isolatedfromabove). * Passes are expected not to modify operations at or above the current operation being processed. If the operation is not isolated, it may diff --git a/mlir/docs/SymbolsAndSymbolTables.md b/mlir/docs/SymbolsAndSymbolTables.md index 4c9b3ae257e3..9078aef898d8 100644 --- a/mlir/docs/SymbolsAndSymbolTables.md +++ b/mlir/docs/SymbolsAndSymbolTables.md @@ -8,7 +8,7 @@ around this nesting structure; including the processing of operations within the [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/#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 diff --git a/mlir/docs/Tutorials/Toy/Ch-2.md b/mlir/docs/Tutorials/Toy/Ch-2.md index cd61bd501752..680136941f6c 100644 --- a/mlir/docs/Tutorials/Toy/Ch-2.md +++ b/mlir/docs/Tutorials/Toy/Ch-2.md @@ -245,7 +245,7 @@ This operation takes zero operands, a `value` to represent the constant value, and returns a single result of [RankedTensorType](../../Dialects/Builtin.md/#rankedtensortype). An operation class inherits from the [CRTP](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) -`mlir::Op` class which also takes some optional [*traits*](../../Traits.md) to +`mlir::Op` class which also takes some optional [*traits*](../../Traits) to customize its behavior. `Traits` are a mechanism with which we can inject additional behavior into an Operation, such as additional accessors, verification, and more. Let's look below at a possible definition for the |