| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][linalg] Genericize MapOp (#162742) This PR modifies the definition of linalg::MapOp so that it has the same structure of linalg::GenericOp and all other linalg ops. Mainly, it adds an out bbarg for the body of the op. Although the out arg is never used in the body, there doesn't seem to be much benefit in specializing the op to exclude it. In fact it only makes things more complicated because it doesn't align with the GenericOp structure. For example, linalg-generalize-named-ops avoided converting linalg.map purely because it didn't have the structure to do so. Moreover, although some fusion patterns are applied explicitly to GenericOp, we can change them to be applied to the base LinalgOp which will enable fusion for any fusion-compatible linalg op, but that requires the op having a generic structure. So these changes will enable us to use existing generic transformation patterns on MapOp that weren't possible before. They can either be applied to MapOp directly or applied after converting to GenericOp. | 8 个月前 | |
[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][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][transform] Clearnup tile_one_consumer_using_tile_and_fuse test (NFC) (#164108) | 9 个月前 | |
[mlir][TilingInterface] Use LoopLikeOpInterface in tiling using SCF to unify tiling with scf.for and scf.forall. (#77874) Using LoopLikeOpInterface as the basis for the implementation unifies all the tiling logic for both scf.for and scf.forall. The only difference is the actual loop generation. This is a follow up to https://github.com/llvm/llvm-project/pull/72178 Instead of many entry points for each loop type, the loop type is now passed as part of the options passed to the tiling method. This is a breaking change with the following changes 1) The scf::tileUsingSCFForOp is renamed to scf::tileUsingSCF 2) The scf::tileUsingSCFForallOp is deprecated. The same functionality is obtained by using scf::tileUsingSCF and setting the loop type in scf::SCFTilingOptions passed into this method to scf::SCFTilingOptions::LoopType::ForallOp (using the setLoopType method). 3) The scf::tileConsumerAndFusedProducerGreedilyUsingSCFForOp is renamed to scf::tileConsumerAndFuseProducerUsingSCF. The use of the controlFn in scf::SCFTileAndFuseOptions allows implementing any strategy with the default callback implemeting the greedy fusion. 4) The scf::SCFTilingResult and scf::SCFTileAndFuseResult now use SmallVector<LoopLikeOpInterface>. 5) To make scf::ForallOp implement the parts of LoopLikeOpInterface needed, the getOutputBlockArguments() method is replaced with getRegionIterArgs() These changes now bring the tiling and fusion capabilities using scf.forall on par with what was already supported by scf.for | 2 年前 | |
[mlir][TilingInterface] Allow tile and fuse to work with ReductionTilingStrategy::PartialReductionOuterParallelStrategy. (#147593) Since scf::tileUsingSCF is the core method used for tiling the root operation within the scf::tileConsumersAndFuseProducersUsingSCF, the latter can fuse into any tiled loop generated using scf::tileUsingSCF. This patch adds a test for tiling a root operation using ReductionTilingStrategy::PartialReductionOuterParallelStrategy and fusing producers with it. Since this strategy generates a rank-reducing extract slice tensor::replaceExtractSliceWithTiledProducer which is the core method used for the fusion was extended to handle the rank-reducing slices. Also fix a small bug in the computation of the reduction induction variable (which needs to use floorDiv instead of ceilDiv) Signed-off-by: MaheshRavishankar <mahesh.ravishankar@gmail.com> | 1 年前 | |
[mlir][scf] Extend option to yield replacement for multiple results case (#93144) This patch extends the functionality of yielding replacement for multiple results case and adds another optional argument called yieldResultNumber indicating which result(s) need yield. If not given, all of results will be yield by default. | 2 年前 | |
[mlir][TilingInterface] Use LoopLikeOpInterface in tiling using SCF to unify tiling with scf.for and scf.forall. (#77874) Using LoopLikeOpInterface as the basis for the implementation unifies all the tiling logic for both scf.for and scf.forall. The only difference is the actual loop generation. This is a follow up to https://github.com/llvm/llvm-project/pull/72178 Instead of many entry points for each loop type, the loop type is now passed as part of the options passed to the tiling method. This is a breaking change with the following changes 1) The scf::tileUsingSCFForOp is renamed to scf::tileUsingSCF 2) The scf::tileUsingSCFForallOp is deprecated. The same functionality is obtained by using scf::tileUsingSCF and setting the loop type in scf::SCFTilingOptions passed into this method to scf::SCFTilingOptions::LoopType::ForallOp (using the setLoopType method). 3) The scf::tileConsumerAndFusedProducerGreedilyUsingSCFForOp is renamed to scf::tileConsumerAndFuseProducerUsingSCF. The use of the controlFn in scf::SCFTileAndFuseOptions allows implementing any strategy with the default callback implemeting the greedy fusion. 4) The scf::SCFTilingResult and scf::SCFTileAndFuseResult now use SmallVector<LoopLikeOpInterface>. 5) To make scf::ForallOp implement the parts of LoopLikeOpInterface needed, the getOutputBlockArguments() method is replaced with getRegionIterArgs() These changes now bring the tiling and fusion capabilities using scf.forall on par with what was already supported by scf.for | 2 年前 | |
[mlir][Linalg] Deprecate linalg::tileToForallOp and linalg::tileToForallOpUsingTileSizes (#91878) The implementation of these methods are legacy and they are removed in favor of using the scf::tileUsingSCF methods as replacements. To get the latter on par with requirements of the deprecated methods, the tiling allows one to specify the maximum number of tiles to use instead of specifying the tile sizes. When tiling to scf.forall this specification is used to generate the num_threads version of the operation. A slight deviation from previous implementation is that the deprecated method always generated the num_threads variant of the scf.forall operation. Instead now this is driven by the tiling options specified. This reduces the indexing math generated when the tile sizes are specified. **Moving from linalg::tileToForallOp to scf::tileUsingSCF** OpBuilder b; TilingInterface op; ArrayRef<OpFoldResult> numThreads; ArrayAttr mapping; FailureOr<ForallTilingResult> result =linalg::tileToForallOp(b, op, numThreads, mapping); can be replaced by scf::SCFTilingOptions options; options.setNumThreads(numThreads); options.setLoopType(scf::SCFTilingOptions::LoopType::ForallOp); options.setMapping(mapping.getValue()); /*note the difference that setMapping takes an ArrayRef<Attribute> */ FailureOr<scf::SCFTilingResult> result = scf::tileUsingSCF(b, op, options); This generates the numThreads version of the scf.forall for the inter-tile loops, i.e. ... = scf.forall (%arg0, %arg1) in (%nt0, %nt1) shared_outs(...) **Moving from linalg::tileToForallOpUsingTileSizes to scf::tileUsingSCF** OpBuilder b; TilingInterface op; ArrayRef<OpFoldResult> tileSizes; ArrayAttr mapping; FailureOr<ForallTilingResult> result =linalg::tileToForallOpUsingTileSizes(b, op, tileSizes, mapping); can be replaced by scf::SCFTilingOptions options; options.setTileSizes(tileSizes); options.setLoopType(scf::SCFTilingOptions::LoopType::ForallOp); options.setMapping(mapping.getValue()); /*note the difference that setMapping takes an ArrayRef<Attribute> */ FailureOr<scf::SCFTilingResult> result = scf::tileUsingSCF(b, op, options); Also note that linalg::tileToForallOpUsingTileSizes would effectively call the linalg::tileToForallOp by computing the numThreads from the op and tileSizes and generate the numThreads version of the scf.forall. That is not the case anymore. Instead this will directly generate the tileSizes version of the scf.forall op ... = scf.forall(%arg0, %arg1) = (%lb0, %lb1) to (%ub0, %ub1) step(%step0, %step1) shared_outs(...) If you actually want to use the numThreads version, it is upto the caller to compute the numThreads and set options.setNumThreads instead of options.setTileSizes. Note that there is a slight difference in the num threads version and tile size version. The former requires an additional affine.max on the tile size to ensure non-negative tile sizes. When lowering to numThreads version this affine.max is not needed since by construction the tile sizes are non-negative. In previous implementations, the numThreads version generated when using the linalg::tileToForallOpUsingTileSizes method would avoid generating the affine.max operation. To get the same state, downstream users will have to additionally normalize the scf.forall operation. **Changes to transform.structured.tile_using_forall** The transform dialect op that called into linalg::tileToForallOp and linalg::tileToForallOpUsingTileSizes have been modified to call scf::tileUsingSCF. The transform dialect op always generates the numThreads version of the scf.forall op. So when tile_sizes are specified for the transform dialect op, first the tile_sizes version of the scf.forall is generated by the scf::tileUsingSCF method which is then further normalized to get back to the same state. So there is no functional change to transform.structured.tile_using_forall. It always generates the numThreads version of the scf.forall op (as it did before this change). --------- Signed-off-by: MaheshRavishankar <mahesh.ravishankar@gmail.com> | 1 年前 | |
[mlir][SCF] Allow using a custom operation to generate loops with mlir::tileUsingSCF. (#159660) This change adds an option to use a custom operation to generate the inter-tile loops during tiling. When the loop type is set to scf::SCFTilingOptions::LoopType::CustomOp, the method mlir::tileUsingSCF provides two callback functions First one to generate the header of the loop. Second one to generate the terminator of the loop. These methods receive the information needed to generate the loops/terminator and expect to return information needed to generate the code for the intra-tile computation. See comments for more details. Presently this is adds support only for tiling. Subsequent commits will update this to add support for fusion as well. The PR is split into two commits. The first commit is an NFC that just refactors the code (and cleans up some naming) to make it easier to add the support for custom loop operations. The second commit adds the support for using a custom loop operation, as well as a test to exercise this path. Note that this is duplicate of https://github.com/llvm/llvm-project/pull/159506 that was accidently committed and was reverted in https://github.com/llvm/llvm-project/pull/159598 to wait for reviews. Signed-off-by: MaheshRavishankar [mahesh.ravishankar@gmail.com](mailto:mahesh.ravishankar@gmail.com) --------- Signed-off-by: MaheshRavishankar <mahesh.ravishankar@gmail.com> | 10 个月前 | |
[mlir][affine]introducing new symbol rules that the result of a Pure operation that whose operands are valid symbolic identifiers (#118478) introducing new symbol rules that the result of a Pure operation that whose operands are valid symbolic identifiers. | 1 年前 | |
[mlir][affine]introducing new symbol rules that the result of a Pure operation that whose operands are valid symbolic identifiers (#118478) introducing new symbol rules that the result of a Pure operation that whose operands are valid symbolic identifiers. | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 |