RRiver Riddle[mlir] Refactor SubElementInterface replace support
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Don't use Optional::hasValue (NFC) | 3 年前 | |
[mlir] (NFC) Clean up bazel and CMake target names All dialect targets in bazel have been named *Dialect and all dialect targets in CMake have been named MLIR*Dialect. | 3 年前 | |
[mlir] (NFC) Clean up bazel and CMake target names All dialect targets in bazel have been named *Dialect and all dialect targets in CMake have been named MLIR*Dialect. | 3 年前 | |
[mlir] move SCF headers to SCF/{IR,Transforms} respectively This aligns the SCF dialect file layout with the majority of the dialects. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D128049 | 3 年前 | |
[mlir][Linalg] Deprecate tileAndFuseLinalgOps method and associated patterns. The tileAndFuseLinalgOps is a legacy approach for tiling + fusion of Linalg operations. Since it was also intended to work on operations with buffer operands, this method had fairly complex logic to make sure tile and fuse was correct even with side-effecting linalg ops. While complex, it still wasnt robust enough. This patch deprecates this method and thereby deprecating the tiling + fusion method for ops with buffer semantics. Note that the core transformation to do fusion of a producer with a tiled consumer still exists. The deprecation here only removes methods that auto-magically tried to tile and fuse correctly in presence of side-effects. The tileAndFuseLinalgOps also works with operations with tensor semantics. There are at least two other ways the same functionality exists. 1) The tileConsumerAndFuseProducers method. This does a similar transformation, but using a slightly different logic to automatically figure out the legal tile + fuse code. Note that this is also to be deprecated soon. 2) The prefered way uses the TilingInterface for tile + fuse, and relies on the caller to set the tiling options correctly to ensure that the generated code is correct. As proof that (2) is equivalent to the functionality provided by tileAndFuseLinalgOps, relevant tests have been moved to use the interface, where the test driver sets the tile sizes appropriately to generate the expected code. Differential Revision: https://reviews.llvm.org/D129901 | 3 年前 | |
[mlir] move SCF headers to SCF/{IR,Transforms} respectively This aligns the SCF dialect file layout with the majority of the dialects. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D128049 | 3 年前 | |
[mlir] (NFC) Clean up bazel and CMake target names All dialect targets in bazel have been named *Dialect and all dialect targets in CMake have been named MLIR*Dialect. | 3 年前 | |
[mlir] move SCF headers to SCF/{IR,Transforms} respectively This aligns the SCF dialect file layout with the majority of the dialects. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D128049 | 3 年前 | |
[mlir] Remove unneeded cl::ZeroOrMore for ListOption variables. NFC | 3 年前 | |
[mlir] (NFC) Clean up bazel and CMake target names All dialect targets in bazel have been named *Dialect and all dialect targets in CMake have been named MLIR*Dialect. | 3 年前 | |
[mlir] Update flipped accessors (NFC) Follow up with memref flipped and flipping any intermediate changes made. | 3 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
[mlir][tosa] Flip accessors used to prefixed form (NFC) Follow up from dialect flip, just flipping accessors. Both forms still generated. | 3 年前 | |
[mlir][linalg] Expand test case for tile-and-fuse with transform dialect Reverse the order of the payload ops. fuse_into_containing_op should still work. Differential Revision: https://reviews.llvm.org/D130355 | 3 年前 | |
[mlir] Remove unneeded cl::ZeroOrMore for ListOption variables. NFC | 3 年前 | |
[mlir] Introduce Transform dialect This dialect provides operations that can be used to control transformation of the IR using a different portion of the IR. It refers to the IR being transformed as payload IR, and to the IR guiding the transformation as transform IR. The main use case for this dialect is orchestrating fine-grain transformations on individual operations or sets thereof. For example, it may involve finding loop-like operations with specific properties (e.g., large size) in the payload IR, applying loop tiling to those and only those operations, and then applying loop unrolling to the inner loops produced by the previous transformations. As such, it is not intended as a replacement for the pass infrastructure, nor for the pattern rewriting infrastructure. In the most common case, the transform IR will be processed and applied to payload IR by a pass. Transformations expressed by the transform dialect may be implemented using the pattern infrastructure or any other relevant MLIR component. This dialect is designed to be extensible, that is, clients of this dialect are allowed to inject additional operations into this dialect using the newly introduced in this patch TransformDialectExtension mechanism. This allows the dialect to avoid a dependency on the implementation of the transformation as well as to avoid introducing dialect-specific transform dialects. See https://discourse.llvm.org/t/rfc-interfaces-and-dialects-for-precise-ir-transformation-control/60927. Reviewed By: nicolasvasilache, Mogball, rriddle Differential Revision: https://reviews.llvm.org/D123135 | 4 年前 |