[mlir][sparse] migrate sparse rewriting to sparse transformations passThe rules in the linalg file were very specific to sparse tensors so willfind a better home under sparse tensor dialect than l
[mlir][sparse] migrate sparse rewriting to sparse transformations passThe rules in the linalg file were very specific to sparse tensors so willfind a better home under sparse tensor dialect than linalg dialect. Alsomoved some rewriting from sparsification into this new "pre-rewriting" file.Reviewed By: springermDifferential Revision: https://reviews.llvm.org/D129910
show more ...
[mlir][sparse] Switch to One-Shot BufferizeThis change removes the partial bufferization passes from the sparse compilation pipeline and replaces them with One-Shot Bufferize. One-Shot Analysis (an
[mlir][sparse] Switch to One-Shot BufferizeThis change removes the partial bufferization passes from the sparse compilation pipeline and replaces them with One-Shot Bufferize. One-Shot Analysis (and TensorCopyInsertion) is used to resolve all out-of-place bufferizations, dense and sparse. Dense ops are then bufferized with BufferizableOpInterface. Sparse ops are still bufferized in the Sparsification pass.Details:* Dense allocations are automatically deallocated, unless they are yielded from a block. (In that case the alloc would leak.) All test cases are modified accordingly. E.g., some funcs now have an "out" tensor argument that is returned from the function. (That way, the allocation happens at the call site.)* Sparse allocations are *not* automatically deallocated. They must be "released" manually. (No change, this will be addressed in a future change.)* Sparse tensor copies are not supported yet. (Future change)* Sparsification no longer has to consider inplacability. If necessary, allocations and/or copies are inserted during TensorCopyInsertion. All tensors are inplaceable by the time Sparsification is running. Instead of marking a tensor as "not inplaceable", it can be marked as "not writable", which will trigger an allocation and/or copy during TensorCopyInsertion.Differential Revision: https://reviews.llvm.org/D129356
[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][sparse] complex loweringReviewed By: bixiaDifferential Revision: https://reviews.llvm.org/D126335
[mlir][sparse] introduce complex type to sparse tensor supportThis is the first implementation of complex (f64 and f32) supportin the sparse compiler, with complex add/mul as first operations.Not
[mlir][sparse] introduce complex type to sparse tensor supportThis is the first implementation of complex (f64 and f32) supportin the sparse compiler, with complex add/mul as first operations.Note that various features are still TBD, such as other ops, andreading in complex values from file. Also, note that thestd::complex<float> had a bit of an ABI issue when passed assingle argument. It is still TBD if better solutions are possible.Reviewed By: bixiaDifferential Revision: https://reviews.llvm.org/D125596
Fix build with shared libs: add missing CMake dep to MLIR sparse pipeline
[mlir][sparse] integration test for zero preserving math opAlso fixes omission in lowering math ops that require lib supportReviewed By: bixiaDifferential Revision: https://reviews.llvm.org/D12
[mlir][sparse] integration test for zero preserving math opAlso fixes omission in lowering math ops that require lib supportReviewed By: bixiaDifferential Revision: https://reviews.llvm.org/D125104
[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][sparse] Introducing options for the SparseTensorConversion passThis is work towards: https://github.com/llvm/llvm-project/issues/51652This differential sets up the options and threads them
[mlir][sparse] Introducing options for the SparseTensorConversion passThis is work towards: https://github.com/llvm/llvm-project/issues/51652This differential sets up the options and threads them through everywhere, but doesn't actually use them yet. The differential that finally makes use of them is D122061, which is the final differential in the chain that fixes bug 51652.Reviewed By: aartbikDifferential Revision: https://reviews.llvm.org/D122054
[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][NFC] Rename StandardToLLVM to FuncToLLVMThe current StandardToLLVM conversion patterns only really handlethe Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, butthose s
[mlir][NFC] Rename StandardToLLVM to FuncToLLVMThe current StandardToLLVM conversion patterns only really handlethe Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, butthose should be/will be split out in a followup. This commit focuses solelyon being an NFC rename.Aside from the directory change, the pattern and pass creation API have been renamed: * populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern * populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns * createLowerToLLVMPass -> createConvertFuncToLLVMPassDifferential Revision: https://reviews.llvm.org/D120778
[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][linalg][sparse] add linalg optimization passes "upstream"It is time to compose Linalg related optimizations with SparseTensorrelated optimizations. This is a careful first start by adding s
[mlir][linalg][sparse] add linalg optimization passes "upstream"It is time to compose Linalg related optimizations with SparseTensorrelated optimizations. This is a careful first start by adding somegeneral Linalg optimizations "upstream" of the sparse compiler in thefull sparse compiler pipeline. Some minor changes were needed to makethose optimizations aware of sparsity.Note that after this, we will add a sparse specific fusion rule,just to demonstrate the power of the new composition.Reviewed By: bixiaDifferential Revision: https://reviews.llvm.org/D119971
[mlir][bufferize] Add vector-bufferize pass and remove obsolete patterns from Linalg BufferizeDifferential Revision: https://reviews.llvm.org/D119444
[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, Co
[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
[mlir][sparse] Updating sparse-compiler pipeline for python usageExplicitly nests passes for FuncOp, adds more options to the sparse-compiler pipeline, and updates python integration tests. This s
[mlir][sparse] Updating sparse-compiler pipeline for python usageExplicitly nests passes for FuncOp, adds more options to the sparse-compiler pipeline, and updates python integration tests. This should be sufficient to close https://github.com/llvm/llvm-project/issues/51751Reviewed By: aartbikDifferential Revision: https://reviews.llvm.org/D118658
[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][bufferize] Merge tensor-constant-bufferize into arith-bufferizeThe bufferization of arith.constant ops is also switched over to BufferizableOpInterface-based bufferization. The old implement
[mlir][bufferize] Merge tensor-constant-bufferize into arith-bufferizeThe bufferization of arith.constant ops is also switched over to BufferizableOpInterface-based bufferization. The old implementation is deleted. Both implementations utilize GlobalCreator, now renamed to just `getGlobalFor`.GlobalCreator no longer maintains a set of all created allocations to avoid duplicate allocations of the same constant. Instead, `getGlobalFor` scans the module to see if there is already a global allocation with the same constant value.For compatibility reasons, it is still possible to create a pass that bufferizes only `arith.constant`. This pass (createConstantBufferizePass) could be deleted once all users were switched over to One-Shot bufferization.Differential Revision: https://reviews.llvm.org/D118483
[mlir][sparse] Adding standard pipeline for tests.Addresses https://bugs.llvm.org/show_bug.cgi?id=52409 aka https://github.com/llvm/llvm-project/issues/51751Reviewed By: aartbik, mehdi_aminiDif
[mlir][sparse] Adding standard pipeline for tests.Addresses https://bugs.llvm.org/show_bug.cgi?id=52409 aka https://github.com/llvm/llvm-project/issues/51751Reviewed By: aartbik, mehdi_aminiDifferential Revision: https://reviews.llvm.org/D117919