Changes in detensorize_while_impure_cf.mlir

92d38adb - [mlir][NFC] Update textual references of `func` to `func.func` in Linalg tests

Wed, 20 Apr 2022 23:16:23 +0000

[mlir][NFC] Update textual references of `func` to `func.func` in Linalg testsThe special case parsing of `func` operations is being removed. List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

36550692 - [mlir] Move the Builtin FuncOp to the Func dialect

Tue, 08 Mar 2022 03:16:03 +0000

[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made FuncOp an operation (years ago). This commit handles thefunctional aspects of the move, but various aspects are left untouchedto ease migration: func::FuncOp is re-exported into mlir to reducethe actual API churn, the assembly format still accepts the unqualified`func`. These temporary measures will remain for a little while tosimplify migration before being removed.Differential Revision: https://reviews.llvm.org/D121266 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

ace01605 - [mlir] Split out a new ControlFlow dialect from Standard

Fri, 04 Feb 2022 04:59:43 +0000

[mlir] Split out a new ControlFlow dialect from StandardThis dialect is intended to model lower level/branch based control-flow constructs. The initial setof operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the currentstandard dialect.See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061Differential Revision: https://reviews.llvm.org/D118966 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

d75c3e83 - [mlir] Don't print `// no predecessors` on entry blocks

Wed, 19 Jan 2022 20:18:30 +0000

[mlir] Don't print `// no predecessors` on entry blocksEntry blocks can never have predecessors, so this is unnecessary.Fixes #53287Differential Revision: https://reviews.llvm.org/D117713 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

550ea385 - [mlir] Remove unnecessary canonicalization from Linalg Detensorize.cpp

Mon, 03 Jan 2022 15:25:00 +0000

[mlir] Remove unnecessary canonicalization from Linalg Detensorize.cppAfter https://reviews.llvm.org/D115821 it became possible to create`tensor` with a single `tensor.from_elements` operation withoutcollapsing tensor shape from `tensor<1xelem_type>` to `tensor`Differential Revision: https://reviews.llvm.org/D115891 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

c10995a8 - Re-apply [NFC] Generalize a couple of passes so they can operate on any FunctionLike op.

Mon, 13 Dec 2021 21:08:54 +0000

Re-apply [NFC] Generalize a couple of passes so they can operate on any FunctionLike op.* Generalizes passes linalg-detensorize, linalg-fold-unit-extent-dims, convert-elementwise-to-linalg.* I feel that more work could be done in the future (i.e. make FunctionLike into a proper OpInterface and extend actions in dialect conversion to be trait based), and this patch would be a good record of why that is useful.* Note for downstreams: * Since these passes are now generic, they do not automatically nest with pass managers set up for implicit nesting. * The Detensorize pass must run on a FunctionLike, and this requires explicit nesting.* Addressed missed comments from the original and per-suggestion removed the assert on FunctionLike in ElementwiseToLinalg and DropUnitDims.cpp, which also is what was causing the integration test to fail.This reverts commit aa8815e42e646a98663af4cf036dbb913ad047a7.Differential Revision: https://reviews.llvm.org/D115671 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

aa8815e4 - Revert "[NFC] Generalize a couple of passes so they can operate on any FunctionLike op."

Mon, 13 Dec 2021 20:41:25 +0000

Revert "[NFC] Generalize a couple of passes so they can operate on any FunctionLike op."This reverts commit 34696e6542894ac63dbfb899b0181c539c223ef1.A test is crashing on the mlir-nvidia bot. List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

34696e65 - [NFC] Generalize a couple of passes so they can operate on any FunctionLike op.

Mon, 13 Dec 2021 05:19:39 +0000

[NFC] Generalize a couple of passes so they can operate on any FunctionLike op.* Generalizes passes linalg-detensorize, linalg-fold-unit-extent-dims, convert-elementwise-to-linalg.* I feel that more work could be done in the future (i.e. make FunctionLike into a proper OpInterface and extend actions in dialect conversion to be trait based), and this patch would be a good record of why that is useful.* Note for downstreams: * Since these passes are now generic, they do not automatically nest with pass managers set up for that. * If running them over nested functions, you must nest explicitly. Upstream has adopted this style but *-opt still has some uses of implicit pipelines via args. See tests for argument changes needed.Differential Revision: https://reviews.llvm.org/D115645 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

b618880e - [mlir] Move `linalg.tensor_expand/collapse_shape` to TensorDialect.

Fri, 10 Dec 2021 11:03:47 +0000

[mlir] Move `linalg.tensor_expand/collapse_shape` to TensorDialect.RFC: https://llvm.discourse.group/t/rfc-reshape-ops-restructuring/3310linalg.fill gets a canonicalizer, because `FoldFillWithTensorReshape` cannot be moved to tensorops (it uses linalg::FillOp inside). Before it was listed as a canonicalization pattern for the reshape operations, now it became a canonicalization for FillOp.Differential Revision: https://reviews.llvm.org/D115502 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

015192c6 - [mlir:DialectConversion] Restructure how argument/target materializations get invoked

Wed, 27 Oct 2021 02:00:10 +0000

[mlir:DialectConversion] Restructure how argument/target materializations get invokedThe current implementation invokes materializationswhenever an input operand does not have a mapping for thedesired type, i.e. it requires materialization at the earliest possiblepoint. This conflicts with goal of dialect conversion (and also thecurrent documentation) which states that a materialization is onlyrequired if the materialization is supposed to persist after theconversion process has finished.This revision refactors this such that whenever a targetmaterialization "might" be necessary, we insert anunrealized_conversion_cast to act as a temporary materialization.This allows for deferring the invocation of the usermaterialization hooks until the end of the conversion process,where we actually have a better sense if it's actuallynecessary. This has several benefits:* In some cases a target materialization hook is no longer necessaryWhen performing a full conversion, there are some situationswhere a temporary materialization is necessary. Moving forward,these users won't need to provide any target materializations,as the temporary materializations do not require the user toprovide materialization hooks.* getRemappedValue can now handle values that haven't been converted yetBefore this commit, it wasn't well supported to get the remappedvalue of a value that hadn't been converted yet (making itdifficult/impossible to convert multiple operations in manysituations). This commit updates getRemappedValue to properlyhandle this case by inserting temporary materializations whennecessary.Another code-health related benefit is that with this change wecan move a majority of the complexity related to materializationsto the end of the conversion process, instead of handling adhocwhile conversion is happening.Differential Revision: https://reviews.llvm.org/D111620 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

a54f4eae - [MLIR] Replace std ops with arith dialect ops

Tue, 12 Oct 2021 23:14:57 +0000

[MLIR] Replace std ops with arith dialect opsPrecursor: https://reviews.llvm.org/D110200Removed redundant ops from the standard dialect that were moved to the`arith` or `math` dialects.Renamed all instances of operations in the codebase and in tests.Reviewed By: rriddle, jpienaarDifferential Revision: https://reviews.llvm.org/D110797 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir

bdcf4b9b - [MLIR][Linalg] Make detensoring cost-model more flexible.

Mon, 20 Sep 2021 07:35:42 +0000

[MLIR][Linalg] Make detensoring cost-model more flexible.So far, the CF cost-model for detensoring was limited to discoveringpure CF structures. This means, if while discovering the CF component,the cost-model found any op that is not detensorable, it gives up ondetensoring altogether. This patch makes it a bit more flexible bycleaning-up the detensorable component from non-detensorable ops withoutgiving up entirely.Reviewed By: silvasDifferential Revision: https://reviews.llvm.org/D109965 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Linalg/detensorize_while_impure_cf.mlir