[mlir][NFC] Update textual references of `func` to `func.func` in Conversion/ testsThe special case parsing of `func` operations is being removed.
[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
[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
show more ...
[mlir] Update FuncOp conversion passes to Pass/InterfacePass<FunctionOpInterface>These passes generally don't rely on any special aspects of FuncOp, and moving allowsfor these passes to be used in
[mlir] Update FuncOp conversion passes to Pass/InterfacePass<FunctionOpInterface>These passes generally don't rely on any special aspects of FuncOp, and moving allowsfor these passes to be used in many more situations. The passes that obviously weren'trelying on invariants guaranteed by a "function" were updated to be generic pass, therest were updated to be FunctionOpinterface InterfacePasses.The test updates are NFC switching from implicit nesting (-pass -pass2) form tothe -pass-pipeline form (generic passes do not implicitly nest as op-specific passes do).Differential Revision: https://reviews.llvm.org/D121190
[mlir] Rename the Standard dialect to the Func dialectThe last remaining operations in the standard dialect all revolve aroundFuncOp/function related constructs. This patch simply handles the init
[mlir] Rename the Standard dialect to the Func dialectThe last remaining operations in the standard dialect all revolve aroundFuncOp/function related constructs. This patch simply handles the initialrenaming (which by itself is already huge), but there are a large numberof cleanups unlocked/necessary afterwards:* Removing a bunch of unnecessary dependencies on Func* Cleaning up the From/ToStandard conversion passes* Preparing for the move of FuncOp to the Func dialectSee the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061Differential Revision: https://reviews.llvm.org/D120624
[mlir] Move SelectOp from Standard to ArithmeticThis is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.Differenti
[mlir] Move SelectOp from Standard to ArithmeticThis is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.Differential Revision: https://reviews.llvm.org/D118648
[mlir][Vector] Support 0-D vectors in `CmpIOp`Following the example of `VectorOfAnyRankOf`, I've done a few changes in the`.td` files to help with adding the support for the 0-D case gradually.R
[mlir][Vector] Support 0-D vectors in `CmpIOp`Following the example of `VectorOfAnyRankOf`, I've done a few changes in the`.td` files to help with adding the support for the 0-D case gradually.Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D115220
[mlir:DialectConversion] Restructure how argument/target materializations get invokedThe current implementation invokes materializationswhenever an input operand does not have a mapping for thede
[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
[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
[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