[mlir] move SCF headers to SCF/{IR,Transforms} respectivelyThis aligns the SCF dialect file layout with the majority of the dialects.Reviewed By: jpienaarDifferential Revision: https://reviews.
[mlir] move SCF headers to SCF/{IR,Transforms} respectivelyThis aligns the SCF dialect file layout with the majority of the dialects.Reviewed By: jpienaarDifferential Revision: https://reviews.llvm.org/D128049
show more ...
[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir][NFC] Shift a bunch of dialect includes from the .h to the .cppNow that dialect constructors are generated in the .cpp file, we candrop all of the dependent dialect includes from the .h file
[mlir][NFC] Shift a bunch of dialect includes from the .h to the .cppNow that dialect constructors are generated in the .cpp file, we candrop all of the dependent dialect includes from the .h file.Differential Revision: https://reviews.llvm.org/D124298
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespaceFuncOp has been moved to the `func` namespace for a little over a month, theusing directive can be dropped now.
[mlir][NFC] Drop a few unnecessary includes from Pass.h
[mlir] Add support for operation-produced successor arguments in BranchOpInterfaceThis patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutabl
[mlir] Add support for operation-produced successor arguments in BranchOpInterfaceThis patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutableSuccessorOperands` for operations, which internally produce arguments to some of the block arguments. A motivating example for this would be an invoke op with a error handling path:```invoke %function(%0) label ^success ^error(%1 : i32)^error(%e: !error, %arg0 : i32): ...```The advantages of this are that any users of `BranchOpInterface` can still argue over remaining block argument operands (such as `%1` in the example above), as well as make use of the modifying capabilities to add more operands, erase an operand etc.The way this patch implements that functionality is via a new class called `SuccessorOperands`, which is now returned by `getSuccessorOperands`. It basically contains an `unsigned` denoting how many operator produced operands exist, as well as a `MutableOperandRange`, which are the usual forwarded operands we are used to. The produced operands are assumed to the first few block arguments, followed by the forwarded operands afterwards. The role of `SuccessorOperands` is to provide various utility functions to modify and query the successor arguments from a `BranchOpInterface`.Differential Revision: https://reviews.llvm.org/D123062
[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"This removes any potential confusion with the `getType` accessorswhich correspond to SSA results of an operation, and makes
[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"This removes any potential confusion with the `getType` accessorswhich correspond to SSA results of an operation, and makes itclear what the intent is (i.e. to represent the type of the function).Differential Revision: https://reviews.llvm.org/D121762
[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
[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