| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[MLIR][DataLayout] Add support for scalable vectors (#89349) This commit extends the data layout to support scalable vectors. For scalable vectors, the TypeSize's scalable field is set accordingly, and the alignment information remains the same as for normal vectors. This behavior is in sync with what LLVM's data layout queries are producing. Before this change, scalable vectors incorrectly returned the same size as "normal" vectors. | 2 年前 | |
DestinationPassingStyle: allow additional non-tensor results Also some simplifications: * outputBufferOperands was unused. * The condition that the number of operands equals the number of inputs plus the number of inits seemed vacuously true (?). Differential Revision: https://reviews.llvm.org/D150376 | 3 年前 | |
[mlir] [DataFlow] Fix bug in int-range-analysis (#126708) When querying the lower bound and upper bound of loop to update the value range of a loop iteration variable, the program point to depend on should be the block corresponding to the iteration variable rather than the loop operation. | 1 年前 | |
[mlir][Interfaces] Add interface methods to allow reifying single result/single dim of result. (#162924) Current implementation of reifyResultShapes forces all implementations to return all dimensions of all results. This can be wasteful when you only require dimensions of one result, or a single dimension of a result. Further this also creates issues with using patterns to resolve the tensor.dim and memref.dim operations since the extra operations created result in the pattern rewriter entering an infinite loop (eventually breaking out of the loop due to the iteration limit on the pattern rewriter). This is demonstrated by some of the test cases added here that hit this limit when using --resolve-shaped-type-result-dims and --resolve-ranked-shaped-type-result-dims. To resolve this issue the interface should allow for creating just the operations needed. This change is the first step in resolving this. The original implementation was done with the restriction in mind that it might not always be possible to compute dimension of a single result or one dimension of a single result in all cases. To account for such cases, two additional interface methods are added - reifyShapeOfResult (which allows reifying dimensions of just one result), has a default implementation that calls reifyResultShapes and returns the dimensions of a single result. - reifyDimOfResult (which allows reifying a single dimension of a single result) has a default implementation that calls reifyDimOfResult and returns the value for the dimension of the result (which in turn for the default case would call reifyDimOfResult). While this change sets up the interface, ideally most operations will implement the refiyDimOfResult when possible. For almost all operations in tree this is true. Subsequent commits will change those incrementally. Some of the tests added here that check that the default implementations for the above method work as expected, also end up hitting the pattern rewriter limit when using --resolve-ranked-shaped-type-result-dims/ --resolve-ranked-shaped-type-result-dims. For testing purposes, a flag is added to these passes that ignore the error returned by the pattern application (this flag is left on by default to maintain current state). Changes required downstream to integrate this change 1. In operation definitions in .td files, for those operations that implement the ReifyRankedShapedTypeOpInterface. def <op-name> : Op<..., [..., DeclareOpInterfaceMethods[ReifyRankedShapedTypeOpInterface]]> should be changed to def <op-name> : Op<..., [..., DeclareOpInterfaceMethods[ReifyRankedShapedTypeOpInterface, [ "reifyResultShapes"]]]> --------- Signed-off-by: MaheshRavishankar <mahesh.ravishankar@gmail.com> | 8 个月前 | |
[mlir] Add function for checking if a block is inside a loop This function returns whether a block is nested inside of a loop. There can be three kinds of loop: 1) The block is nested inside of a LoopLikeOpInterface 2) The block is nested inside another block which is in a loop 3) There is a cycle in the control flow graph This will be useful for Flang's stack arrays pass, which moves array allocations from the heap to the stack. Special handling is needed when allocations occur inside of loops to ensure additional stack space is not allocated on each loop iteration. Differential Revision: https://reviews.llvm.org/D141401 | 3 年前 | |
[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 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 8 个月前 |