Revision tags: llvmorg-18.1.8, llvmorg-18.1.7 |
|
#
2b2ce50f |
| 01-Jun-2024 |
Abhishek Varma <abhvarma@amd.com> |
[MLIR][SCF] Add an API to fuse consumer to a producer within scf loop (#88712)
This commit adds an API (`tileAndFuseConsumerOfSlice`) to fuse consumer to a producer within
scf.for/scf.forall loop.
[MLIR][SCF] Add an API to fuse consumer to a producer within scf loop (#88712)
This commit adds an API (`tileAndFuseConsumerOfSlice`) to fuse consumer to a producer within
scf.for/scf.forall loop.
To support this two new methods are added to the `TilingInterface`
- `getIterationDomainTileFromOperandTile`
- `getTiledImplementationFromOperandTile`.
Consumer operations that implement this method can be used to be fused with tiled producer operands in a manner similar to (but essentially the inverse of) the fusion of an untiled producer with a tiled consumer.
Note that this only does one `tiled producer` -> `consumer` fusion. This could be called repeatedly for fusing multiple consumers. The current implementation also is conservative in when this kicks in (like single use of the value returned by the inter-tile loops that surround the tiled producer, etc.) These can be relaxed over time.
Signed-off-by: Abhishek Varma <abhvarma@amd.com>
---------
Signed-off-by: Abhishek Varma <abhvarma@amd.com>
Signed-off-by: Abhishek Varma <avarma094@gmail.com>
Co-authored-by: cxy <chenxunyu1993@gmail.com>
show more ...
|
Revision tags: llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4 |
|
#
809e3d8c |
| 02-Mar-2023 |
Mahesh Ravishankar <ravishankarm@google.com> |
[mlir][TilingInterface] Modify `TilingInterface` methods to better return the state of the transformed IR.
Currently the `getTiledImplementation` and `generateResultTileValue` return just `SmallVect
[mlir][TilingInterface] Modify `TilingInterface` methods to better return the state of the transformed IR.
Currently the `getTiledImplementation` and `generateResultTileValue` return just `SmallVector<Operation *>` and `FailureOr<Value>`.
- For `getTiledImplementation` returning empty implies tiling wasnt done. There is also an implicit assumption that the tiled operation results correspond to the tiled values of the result of the original operation. This cannot handle cases where the tiled implementation might use multiple operations to compute the tiled value for the results of the untiled operation. Sometimes, the tiled operation might not directly give the tiled values, and might require casts, etc to get a replacement. - For `generateResultTileValue`, it is assumed that the op defining the returned `Value` is the operation that represents the tiled computation. Again presence of casts, etc violate this.
Instead make these methods return ``` struct TilingResult { SmallVector<Operation *> tiledOps; SmallVector<Value> tiledValues; }; ```
The `tiledOps` represent the operations generated that are relevant for subsequent transformations. The `tiledValues` represent the tiled values for the results of the original operation. This better transmits the state of the transformed IR.
As a consequence the following methods also return `FailureOr<TilingResult>` - `tensor::replaceExtractSliceWithTiledProducer` - `tensor::bubbleUpPadSlice`
Differential Revision: https://reviews.llvm.org/D145133
show more ...
|
Revision tags: llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
cbb09813 |
| 17-Dec-2022 |
Fangrui Song <i@maskray.me> |
[mlir] llvm::Optional::value => operator*/operator->
std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS
[mlir] llvm::Optional::value => operator*/operator->
std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The call sites block std::optional migration.
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2 |
|
#
abc362a1 |
| 29-Sep-2022 |
Jakub Kuderski <kubak@google.com> |
[mlir][arith] Change dialect name from Arithmetic to Arith
Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.
Tested with: `ninja check-mlir check-ml
[mlir][arith] Change dialect name from Arithmetic to Arith
Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.
Tested with: `ninja check-mlir check-mlir-integration check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner check-mlir-examples`
and `bazel build --config=generic_clang @llvm-project//mlir:all`.
Reviewed By: lattner, Mogball, rriddle, jpienaar, mehdi_amini
Differential Revision: https://reviews.llvm.org/D134762
show more ...
|
#
2d3b54fe |
| 21-Sep-2022 |
Lei Zhang <antiagainst@google.com> |
[mlir][tensor] NFC: name various Transforms/ files consistently
Use a suffix to make clear what the contents inside each file are.
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.l
[mlir][tensor] NFC: name various Transforms/ files consistently
Use a suffix to make clear what the contents inside each file are.
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.llvm.org/D134202
show more ...
|