| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[MLIR] Revamp RegionBranchOpInterface (#165429) This is still somehow a WIP, we have some issues with this interface that are not trivial to solve. This patch tries to make the concepts of RegionBranchPoint and RegionSuccessor more robust and aligned with their definition: - A RegionBranchPoint is either the parent (RegionBranchOpInterface) op or a RegionBranchTerminatorOpInterface operation in a nested region. - A RegionSuccessor is either one of the nested region or the parent RegionBranchOpInterface Some new methods with reasonnable default implementation are added to help resolving the flow of values across the RegionBranchOpInterface. It is still not trivial in the current state to walk the def-use chain backward with this interface. For example when you have the 3rd block argument in the entry block of a for-loop, finding the matching operands requires to know about the hidden loop iterator block argument and where the iterargs start. The API is designed around forward-tracking of the chain unfortunately. Try to reland #161575 ; I suspect a buildbot incremental build issue. | 8 个月前 | |
[mlir][NFC] update mlir/Dialect create APIs (28/n) (#150641) See https://github.com/llvm/llvm-project/pull/147168 for more info. | 11 个月前 | |
[MLIR][Vector] Add unroll pattern for vector.shape_cast (#167738) This PR adds pattern for unrolling shape_cast given a targetShape. This PR is a follow up of #164010 which was very general and was using inserts and extracts on each element (which is also LowerVectorShapeCast.cpp is doing). After doing some more research on use cases, we (me and @Jianhui-Li ) realized that the previous version in #164010 is unnecessarily generic and doesn't fit our performance needs. Our use case requires that targetShape is contiguous in both source and result vector. This pattern only applies when contiguous slices can be extracted from the source vector and inserted into the result vector such that each slice remains in vector form with targetShape (and not decompose to scalars). In these cases, the unrolling proceeds as: vector.extract_strided_slice -> vector.shape_cast (on the slice unrolled) -> vector.insert_strided_slice | 8 个月前 | |
[MLIR][ODS] Add support for overloading interface methods (#161828) This allows to define multiple interface methods with the same name but different arguments. | 9 个月前 | |
[mlir][SCF] Add scf::tileAndFuseConsumer that tiles a consumer into a given tiled loop nest. (#167634) The existing scf::tileAndFuseConsumerOfSlices takes a list of slices (and loops they are part of), tries to find the consumer of these slices (all slices are expected to be the same consumer), and then tiles the consumer into the loop nest using the TilingInterface. A more natural way of doing consumer fusion is to just start from the consumer, look for operands that are produced by the loop nest passed in as loops (presumably these loops are generated by tiling, but that is not a requirement for consumer fusion). Using the consumer you can find the slices of the operands that are accessed within the loop which you can then use to tile and fuse the consumer (using TilingInterface). This handles more naturally the case where multiple operands of the consumer come from the loop nest. The scf::tileAndFuseConsumerOfSlices was implemented as a mirror of scf::tileAndFuseProducerOfSlice. For the latter, the slice has a single producer for the source of the slice, which makes it a natural way of specifying producer fusion. But for consumers, the result might have multiple users, resulting in multiple candidates for fusion, as well as a fusion candidate using multiple results from the tiled loop nest. This means using slices (tensor.insert_slice/tensor.parallel_insert_slice) as a hook for consumer fusion turns out to be quite hard to navigate. The use of the consumer directly avoids all those pain points. In time the scf::tileAndFuseConsumerOfSlices should be deprecated in favor of scf::tileAndFuseConsumer. There is a lot of tech-debt that has accumulated in scf::tileAndFuseConsumerOfSlices that needs to be cleanedup. So while that gets cleaned up, and required functionality is moved to scf::tileAndFuseConsumer, the old path is still maintained. The test for scf::tileAndFuseConsumerUsingSlices is copied to tile-and-fuse-consumer.mlir to tile-and-fuse-consumer-using-slices.mlir. All the tests that were there in this file are now using the tileAndFuseConsumer method. The test op test.tile_and_fuse_consumer is modified to call scf::tileAndFuseConsumer, while a new op test.tile_and_fuse_consumer_of_slice is used to keep the old path tested while it is deprecated. --------- Signed-off-by: MaheshRavishankar <mahesh.ravishankar@gmail.com> | 8 个月前 | |
[MLIR] Implement remark emitting policies in MLIR (#161202) This update introduces two new remark emitting policies: 1. RemarkEmittingPolicyAll, which emits all remarks, 2. RemarkEmittingPolicyFinal, which only emits final remarks after processing. The RemarkEngine is modified to support these policies, allowing for more flexible remark handling based on user configuration. PR also adds flag to mlir-opt --remark-policy=<value> - Specify the policy for remark output. =all - Print all remarks =final - Print final remarks Relanding https://github.com/llvm/llvm-project/pull/160526 This PR requires RemarkEngine to be finalize manually. So here is usage: MLIRContext ctx; ctx.setRemarkEngine(...) ... ctx.getRemarkEngine().shutdown() <-- PR adds this, it is required when the emission policy is final | 9 个月前 | |
Reapply "[mlir] Link libraries that aren't included in libMLIR to libMLIR" (#123910) Use mlir_target_link_libraries() to link dependencies of libraries that are not included in libMLIR, to ensure that they link to the dylib when they are used in Flang. Otherwise, they implicitly pull in all their static dependencies, effectively causing Flang binaries to simultaneously link to the dylib and to static libraries, which is never a good idea. I have only covered the libraries that are used by Flang. If you wish, I can extend this approach to all non-libMLIR libraries in MLIR, making MLIR itself also link to the dylib consistently. [v3 with more -DBUILD_SHARED_LIBS=ON fixes] | 1 年前 | |
[MLIR][PDL] Skip over all results in the PDL Bytecode if a Constraint/Rewrite failed (#139255) Skipping only over the first results leads to the curCodeIt pointing to the wrong location in the bytecode, causing the execution to continue with a wrong instruction after the Constraint/Rewrite. Signed-off-by: Rickert, Jonas <Jonas.Rickert@amd.com> | 1 年前 | |
Reapply "[mlir] Link libraries that aren't included in libMLIR to libMLIR" (#123910) Use mlir_target_link_libraries() to link dependencies of libraries that are not included in libMLIR, to ensure that they link to the dylib when they are used in Flang. Otherwise, they implicitly pull in all their static dependencies, effectively causing Flang binaries to simultaneously link to the dylib and to static libraries, which is never a good idea. I have only covered the libraries that are used by Flang. If you wish, I can extend this approach to all non-libMLIR libraries in MLIR, making MLIR itself also link to the dylib consistently. [v3 with more -DBUILD_SHARED_LIBS=ON fixes] | 1 年前 | |
[MLIR] Improve in-place folding to iterate until fixed-point (#160615) When executed in the context of canonicalization, the folders are invoked in a fixed-point iterative process. However in the context of an API like createOrFold() or in DialectConversion for example, we expect a "one-shot" call to fold to be as "folded" as possible. However, even when folders themselves are indempotent, folders on a given operation interact with each other. For example: // X = 0 + Y %X = arith.addi %c_0, %Y : i32 should fold to %Y, but the process actually involves first the folder provided by the IsCommutative trait to move the constant to the right. However this happens after attempting to fold the operation and the operation folder isn't attempt again after applying the trait folder. This commit makes sure we iterate until fixed point on folder applications. Fixes #159844 | 9 个月前 | |
[mlir][TilingInterface] Add pattern to tile using TilingInterface and implement TilingInterface for Linalg ops. This patch adds support for tiling operations that implement the TilingInterface. - It separates the loop constructs that are used to iterate over tile from the implementation of the tiling itself. For example, the use of destructive updates is more related to use of scf.for for iterating over tiles that are tensors. - To test the transformation, TilingInterface is implemented for LinalgOps. The separation of the looping constructs used from the implementation of tile code generation greatly simplifies the latter. - The implementation of TilingInterface for LinalgOp is kept as an external model for now till this approach can be fully flushed out to replace the existing tiling + fusion approaches in Linalg. Differential Revision: https://reviews.llvm.org/D127133 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 11 个月前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 4 年前 |