[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] Trim a huge number of unnecessary dependencies on the Func dialectThe Func has a large number of legacy dependencies carried over from the oldStandard dialect, which was pervasive and conta
[mlir] Trim a huge number of unnecessary dependencies on the Func dialectThe Func has a large number of legacy dependencies carried over from the oldStandard dialect, which was pervasive and contained a large number of variedoperations. With the split of the standard dialect and its demise, a lot of lingeringdead dependencies have survived to the Func dialect. This commit removes alarge majority of then, greatly reducing the dependence surface area of theFunc dialect.
show more ...
[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] Finish replacing OwningRewritePatternList with RewritePatternSetOwningRewritePatternList has been deprecated for ~10 months now, we can removethe leftover using directives at this point.D
[mlir] Finish replacing OwningRewritePatternList with RewritePatternSetOwningRewritePatternList has been deprecated for ~10 months now, we can removethe leftover using directives at this point.Differential Revision: https://reviews.llvm.org/D118287
[mlir] Add more missing dependencies after D118062These used to be covered transitively, but now need to be explicit.
[mlir:ArmSVE][NFC] Remove dead code and unnecessary dependenciesDifferential Revision: https://reviews.llvm.org/D117981
[mlir][RFC] Add scalable dimensions to VectorTypeWith VectorType supporting scalable dimensions, we don't need many ofthe operations currently present in ArmSVE, like mask generation andbasic ari
[mlir][RFC] Add scalable dimensions to VectorTypeWith VectorType supporting scalable dimensions, we don't need many ofthe operations currently present in ArmSVE, like mask generation andbasic arithmetic instructions. Therefore, this patch also getsrid of those.Having built-in scalable vector support also simplifies the lowering ofscalable vector dialects down to LLVMIR.Scalable dimensions are indicated with the scalable dimensionsbetween square brackets: vector<[4]xf32>Is a scalable vector of 4 single precission floating point elements.More generally, a VectorType can have a set of fixed-length dimensionsfollowed by a set of scalable dimensions: vector<2x[4x4]xf32>Is a vector with 2 scalable 4x4 vectors of single precission floatingpoint elements.The scale of the scalable dimensions can be obtained with the Vectoroperation: %vs = vector.vscaleThis change is being discussed in the discourse RFC:https://llvm.discourse.group/t/rfc-add-built-in-support-for-scalable-vector-types/4484Differential Revision: https://reviews.llvm.org/D111819
[mlir:OpConversionPattern] Add overloads for taking an Adaptor instead of ArrayRefThis has been a TODO for a long time, and it brings about many advantages (namely nice accessors, and less fragile
[mlir:OpConversionPattern] Add overloads for taking an Adaptor instead of ArrayRefThis has been a TODO for a long time, and it brings about many advantages (namely nice accessors, and less fragile code). The existing overloads that accept ArrayRef are now treated as deprecated and will be removed in a followup (after a small grace period). Most of the upstream MLIR usages have been fixed by this commit, the rest will be handled in a followup.Differential Revision: https://reviews.llvm.org/D110293
[mlir] factor memref-to-llvm lowering out of std-to-llvmAfter the MemRef has been split out of the Standard dialect, theconversion to the LLVM dialect remained as a huge monolithic pass.This is u
[mlir] factor memref-to-llvm lowering out of std-to-llvmAfter the MemRef has been split out of the Standard dialect, theconversion to the LLVM dialect remained as a huge monolithic pass.This is undesirable for the same complexity management reasons as havinga huge Standard dialect itself, and is even more confusing given theexistence of a separate dialect. Extract the conversion of the MemRefdialect operations to LLVM into a separate library and a separateconversion pass.Reviewed By: herhut, silvasDifferential Revision: https://reviews.llvm.org/D105625
[mlir][ArmSVE] Add basic load/store operationsArmSVE-specific memory operations are needed to generate end-to-endcode for as long as MLIR core doesn't support scalable vectors. Thisinstructions w
[mlir][ArmSVE] Add basic load/store operationsArmSVE-specific memory operations are needed to generate end-to-endcode for as long as MLIR core doesn't support scalable vectors. Thisinstructions will be eventually unnecessary, for now they're requiredfor more complex testing.Differential Revision: https://reviews.llvm.org/D103535
[mlir][ArmSVE] Add basic mask generation operationsThese `arm_sve.cmp` functions are needed to generate scalable vectormasks as long as scalable vectors are not part of the standard types.Once in
[mlir][ArmSVE] Add basic mask generation operationsThese `arm_sve.cmp` functions are needed to generate scalable vectormasks as long as scalable vectors are not part of the standard types.Once in standard, these can be removed and `std.cmp` can be usedinstead.Differential Revision: https://reviews.llvm.org/D103473
Revert "[mlir][ArmSVE] Add basic mask generation operations"This reverts commit 392af6a78bb7dfb87a24ed66db598c1d09ac756b
[mlir][ArmSVE] Add masked arithmetic operationsThese instructions map to SVE-specific instrinsics that accept apredicate operand to support control flow in vector code.Differential Revision: htt
[mlir][ArmSVE] Add masked arithmetic operationsThese instructions map to SVE-specific instrinsics that accept apredicate operand to support control flow in vector code.Differential Revision: https://reviews.llvm.org/D100982
[mlir][ArmSVE] Add basic arithmetic operationsWhile we figure out how to best add Standard support for scalablevectors, these instructions provide a workaround for basic arithmeticbetween scalabl
[mlir][ArmSVE] Add basic arithmetic operationsWhile we figure out how to best add Standard support for scalablevectors, these instructions provide a workaround for basic arithmeticbetween scalable vectors.Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D100837
[mlir][ArmSVE] Cleanup dialect registrationArmSVE dialect is behind the recent changes in how the Vector dialectinteracts with backend vector dialects and the MLIR -> LLVM IRtranslation module. T
[mlir][ArmSVE] Cleanup dialect registrationArmSVE dialect is behind the recent changes in how the Vector dialectinteracts with backend vector dialects and the MLIR -> LLVM IRtranslation module. This patch cleans up ArmSVE initialization withinVector and removes the need for an LLVMArmSVE dialect.Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D100171