[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] 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] 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] 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.
[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:Analysis] Move the LoopAnalysis library to Dialect/Affine/AnalysisThe current state of the top level Analysis/ directory is that it contains two libraries;a generic Analysis library (free fr
[mlir:Analysis] Move the LoopAnalysis library to Dialect/Affine/AnalysisThe current state of the top level Analysis/ directory is that it contains two libraries;a generic Analysis library (free from dialect dependencies), and a LoopAnalysis librarythat contains various analysis utilities that originated from Affine loop transformations.This commit moves the LoopAnalysis to the more appropriate home of `Dialect/Affine/Analysis/`,given the use and intention of the majority of the code within it. After the move, if thereare generic utilities that would fit better in the top-level Analysis/ directory, we can movethem.Differential Revision: https://reviews.llvm.org/D117351
Apply clang-tidy fixes for performance-for-range-copy to MLIR (NFC)
[mlir][linalg] Replace LinalgOps.h and LinalgTypes.h by a single header.After removing the range type, Linalg does not define any type. The revision thus consolidates the LinalgOps.h and LinalgType
[mlir][linalg] Replace LinalgOps.h and LinalgTypes.h by a single header.After removing the range type, Linalg does not define any type. The revision thus consolidates the LinalgOps.h and LinalgTypes.h into a single Linalg.h header. Additionally, LinalgTypes.cpp is renamed to LinalgDialect.cpp to follow the convention adopted by other dialects such as the tensor dialect.Depends On D115727Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D115728
[mlir] Move memref.[tensor_load|buffer_cast|clone] to "bufferization" dialect.https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712Differential Revision: https://reviews.l
[mlir] Move memref.[tensor_load|buffer_cast|clone] to "bufferization" dialect.https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712Differential Revision: https://reviews.llvm.org/D114552
[mlir][linalg] Remove ConstraintsSet classThe same functionality can be implemented with FlatAffineValueConstraints.Differential Revision: https://reviews.llvm.org/D108179
[mlir][linalg] Improve implementation of hoist padding.Instead of relying on adhoc bounds calculations, use a projection-basedimplementation. This simplifies the implementation and finds more stat
[mlir][linalg] Improve implementation of hoist padding.Instead of relying on adhoc bounds calculations, use a projection-basedimplementation. This simplifies the implementation and finds more staticconstant sizes than previously/Differential Revision: https://reviews.llvm.org/D106054
[mlir][linalg] Cleanup LinalgOp usage in dependence analysis (NFC).Replace the uses of deprecated Structured Op Interface methods in DependenceAnalysis.cpp and DependenceAnalysis.h. This patch is b
[mlir][linalg] Cleanup LinalgOp usage in dependence analysis (NFC).Replace the uses of deprecated Structured Op Interface methods in DependenceAnalysis.cpp and DependenceAnalysis.h. This patch is based on https://reviews.llvm.org/D103394.Differential Revision: https://reviews.llvm.org/D103411
[mlir][linalg] Add support for WAW fusion on tensors.Differential Revision: https://reviews.llvm.org/D100603
[MLIR] Create memref dialect and move dialect-specific ops from std.Create the memref dialect and move dialect-specific opsfrom std dialect to this dialect.Moved ops:AllocOp -> MemRef_AllocOpA
[MLIR] Create memref dialect and move dialect-specific ops from std.Create the memref dialect and move dialect-specific opsfrom std dialect to this dialect.Moved ops:AllocOp -> MemRef_AllocOpAllocaOp -> MemRef_AllocaOpAssumeAlignmentOp -> MemRef_AssumeAlignmentOpDeallocOp -> MemRef_DeallocOpDimOp -> MemRef_DimOpMemRefCastOp -> MemRef_CastOpMemRefReinterpretCastOp -> MemRef_ReinterpretCastOpGetGlobalMemRefOp -> MemRef_GetGlobalOpGlobalMemRefOp -> MemRef_GlobalOpLoadOp -> MemRef_LoadOpPrefetchOp -> MemRef_PrefetchOpReshapeOp -> MemRef_ReshapeOpStoreOp -> MemRef_StoreOpSubViewOp -> MemRef_SubViewOpTransposeOp -> MemRef_TransposeOpTensorLoadOp -> MemRef_TensorLoadOpTensorStoreOp -> MemRef_TensorStoreOpTensorToMemRefOp -> MemRef_BufferCastOpViewOp -> MemRef_ViewOpThe roadmap to split the memref dialect from std is discussed here:https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667Differential Revision: https://reviews.llvm.org/D98041
[mlir][Linalg] Extend tile+fuse to work on Linalg operation on tensors.Differential Revision: https://reviews.llvm.org/D93086
[mlir][Linalg] NFC: Refactor LinalgDependenceGraphElem to allowrepresenting dependence from producer result to consumer.With Linalg on tensors the dependence between operations can be fromthe res
[mlir][Linalg] NFC: Refactor LinalgDependenceGraphElem to allowrepresenting dependence from producer result to consumer.With Linalg on tensors the dependence between operations can be fromthe result of the producer to the consumer. This change just does aNFC refactoring of the LinalgDependenceGraphElem to allow representingboth OpResult and OpOperand*.Differential Revision: https://reviews.llvm.org/D95208
[mlir][Linalg] Revisit the Linalg on tensors abstractionThis revision drops init_tensor arguments from Linalg on tensors and instead uniformizes the output buffers and output tensors to be consiste
[mlir][Linalg] Revisit the Linalg on tensors abstractionThis revision drops init_tensor arguments from Linalg on tensors and instead uniformizes the output buffers and output tensors to be consistent.This significantly simplifies the usage of Linalg on tensors and is a stepping stone forits evolution towards a mixed tensor and shape abstraction discussed in https://llvm.discourse.group/t/linalg-and-shapes/2421/19.Differential Revision: https://reviews.llvm.org/D93469
[mlir] Allow RegionBranchOps in dependence analysisThis is to prevent assertion failures on scf.if and shape.assumingoperations where this is not enough information currently to handle anyaliasin
[mlir] Allow RegionBranchOps in dependence analysisThis is to prevent assertion failures on scf.if and shape.assumingoperations where this is not enough information currently to handle anyaliasing information.Differential Revision: https://reviews.llvm.org/D92963
[mlir][Linalg] Add dependence type to LinalgDependenceGraphElem.Differential Revision: https://reviews.llvm.org/D91502
[mlir][linalg] Allow tensor_to_memref in dependence analysisThis enables the use of fusion on buffers in partially loweredprograms.Differential Revision: https://reviews.llvm.org/D91613
[mlir][Linalg] Change LinalgDependenceGraph to use LinalgOp.Using LinalgOp will reduce the repeated conversion from Operation <->LinalgOp.Differential Revision: https://reviews.llvm.org/D91101
[mlir][Linalg] Improve the logic to perform tile and fuse with better dependence tracking.This change does two main things1) An operation might have multiple dependences to the same producer. N
[mlir][Linalg] Improve the logic to perform tile and fuse with better dependence tracking.This change does two main things1) An operation might have multiple dependences to the same producer. Not tracking them correctly can result in incorrect code generation with fusion. To rectify this the dependence tracking needs to also have the operand number in the consumer.2) Improve the logic used to find the fused loops making it easier to follow. The only constraint for fusion is that linalg ops (on buffers) have update semantics for the result. Fusion should be such that only one iteration of the fused loop (which is also a tiled loop) must touch only one (disjoint) tile of the output. This could be relaxed by allowing for recomputation that is the default when oeprands are tensors, or can be made legal with promotion of the fused view (in future).Differential Revision: https://reviews.llvm.org/D90579
[mlir][Linalg] Add more utility functions to LinalgDependenceGraph.Reviewed By: ThomasRaouxDifferential Revision: https://reviews.llvm.org/D90582
[mlir][Linalg] Add basic support for TileAndFuse on Linalg on tensors.This revision allows the fusion of the producer of input tensors in the consumer under a tiling transformation (which produces
[mlir][Linalg] Add basic support for TileAndFuse on Linalg on tensors.This revision allows the fusion of the producer of input tensors in the consumer under a tiling transformation (which produces subtensors).Many pieces are still missing (e.g. support init_tensors, better refactor LinalgStructuredOp interface support, try to merge implementations and reuse code) but this still allows getting started.The greedy pass itself is just for testing purposes and will be extracted in a separate test pass.Differential revision: https://reviews.llvm.org/D89491
[mlir][Linalg] Add some depedence query methods to LinalgDependenceGraph.The methods allow to check- if an operation has dependencies,- if there is a dependence from one operation to another.Di
[mlir][Linalg] Add some depedence query methods to LinalgDependenceGraph.The methods allow to check- if an operation has dependencies,- if there is a dependence from one operation to another.Differential Revision: https://reviews.llvm.org/D88993
123