| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][vector] Support complete folding in single pass for vector.insert/vector.extract (#142124) ### Description This patch improves the folding efficiency of vector.insert and vector.extract operations by not returning early after successfully converting dynamic indices to static indices. This PR also renames the test pass TestConstantFold to TestSingleFold and adds comprehensive documentation explaining the single-pass folding behavior. ### Motivation Since the OpBuilder::createOrFold function only calls fold **once**, the current fold methods of vector.insert and vector.extract may leave the op in a state that can be folded further. For example, consider the following un-folded IR: %v1 = vector.insert %e1, %v0 [0] : f32 into vector<128xf32> %c0 = arith.constant 0 : index %e2 = vector.extract %v1[%c0] : f32 from vector<128xf32> If we use createOrFold to create the vector.extract op, then the result will be: %v1 = vector.insert %e1, %v0 [127] : f32 into vector<128xf32> %e2 = vector.extract %v1[0] : f32 from vector<128xf32> But this is not the optimal result. createOrFold should have returned %e1. The reason is that the execution of fold returns immediately after extractInsertFoldConstantOp, causing subsequent folding logics to be skipped. --------- Co-authored-by: Yang Bai <yangb@nvidia.com> | 1 年前 | |
[mlir] Enable decoupling two kinds of greedy behavior. (#104649) The greedy rewriter is used in many different flows and it has a lot of convenience (work list management, debugging actions, tracing, etc). But it combines two kinds of greedy behavior 1) how ops are matched, 2) folding wherever it can. These are independent forms of greedy and leads to inefficiency. E.g., cases where one need to create different phases in lowering and is required to applying patterns in specific order split across different passes. Using the driver one ends up needlessly retrying folding/having multiple rounds of folding attempts, where one final run would have sufficed. Of course folks can locally avoid this behavior by just building their own, but this is also a common requested feature that folks keep on working around locally in suboptimal ways. For downstream users, there should be no behavioral change. Updating from the deprecated should just be a find and replace (e.g., find ./ -type f -exec sed -i 's|applyPatternsAndFoldGreedily|applyPatternsGreedily|g' {} \; variety) as the API arguments hasn't changed between the two. | 1 年前 | |
[mlir][pass] Add composite pass utility (#87166) Composite pass allows to run sequence of passes in the loop until fixed point or maximum number of iterations is reached. The usual candidates are canonicalize+CSE as canonicalize can open more opportunities for CSE and vice-versa. | 2 年前 | |
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace FuncOp has been moved to the func namespace for a little over a month, the using directive can be dropped now. | 4 年前 | |
[mlir][NFC] update mlir/Dialect create APIs (28/n) (#150641) See https://github.com/llvm/llvm-project/pull/147168 for more info. | 1 年前 | |
[mlir:PDLL] Don't require users to provide operands/results when all are variadic When all operands or results are variadic, zero values is a perfectly valid behavior to expect, and we shouldn't force the user to provide values in this case. For example, when creating a call or a return operation we often don't want/need to provide return values. Differential Revision: https://reviews.llvm.org/D133721 | 3 年前 | |
[mlir][inliner] Add doClone and canHandleMultipleBlocks callbacks to Inliner Config (#131226) Current inliner disables inlining when the caller is in a region with single block trait, while the callee function contains multiple blocks. the SingleBlock trait is used in operations such as do/while loop, for example fir.do_loop, fir.iterate_while and fir.if. Typically, calls within loops are good candidates for inlining. However, functions with multiple blocks are also common. for example, any function with "if () then return" will result in multiple blocks in MLIR. This change gives the flexibility of a customized inliner to handle such cases. doClone: clones instructions and other information from the callee function into the caller function. . canHandleMultipleBlocks: checks if functions with multiple blocks can be inlined into a region with the SingleBlock trait. The default behavior of the inliner remains unchanged. --------- Co-authored-by: jeanPerier <jean.perier.polytechnique@gmail.com> Co-authored-by: Mehdi Amini <joker.eph@gmail.com> | 1 年前 | |
[mlir][NFC] update mlir/Dialect create APIs (28/n) (#150641) See https://github.com/llvm/llvm-project/pull/147168 for more info. | 1 年前 | |
[MLIR] getBackwardSlice: don't bail on ops that are IsolatedFromAbove (#158135) Ops with the IsIsolatedFromAbove trait should be captured by the backward slice. --------- Signed-off-by: Ian Wood <ianwood@u.northwestern.edu> | 10 个月前 | |
[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 | 10 个月前 | |
[MLIR] Apply clang-tidy fixes for llvm-qualified-auto in TestTransformsOps.cpp (NFC) | 10 个月前 | |
[mlir][affine] Fix min simplification in makeComposedAffineApply (#145376) This patch fixes a bug discovered in the affine::makeComposedFoldedAffineApply function when composeAffineMin == true. The bug happened because the simplification assumed the symbols appearing in the affine.apply op corresponded to symbols in the affine.min op, and that's not always the case. For example: mlir #map = affine_map<()[s0, s1] -> (s1)> #map1 = affine_map<()[s0, s1] -> (s0 ceildiv s1)> module { func.func @min_max_full_simplify() -> index { %0 = test.value_with_bounds {max = 64 : index, min = 32 : index} %1 = test.value_with_bounds {max = 64 : index, min = 32 : index} %2 = affine.min #map()[%0, %1] %3 = affine.apply #map1()[%2, %0] return %3 : index } } This patch also introduces the test make_composed_folded_affine_apply transform operation to test this simplification. It also adds tests ensuring we get correct behavior. --------- Co-authored-by: Nicolas Vasilache <nico.vasilache@amd.com> | 1 年前 | |
[mlir] Add a utility method to move operation dependencies. (#129975) The added utility method moves all SSA values that an operation depends upon before an insertion point. This is useful during transformations where such movements might make transformations (like fusion) more powerful. To test the operation add a transform dialect op that calls the move operation. To be able to capture the notifyMatchFailure messages from the transformation and to report/check these in the test modify the ErrorCheckingTrackingListener to capture the last match failure notification. --------- Signed-off-by: MaheshRavishankar <mahesh.ravishankar@gmail.com> | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 |