[mlir] Fix the names of exported functionsThe names of the functions that are supposed to be exported do not match the implementations. This is due in part to https://github.com/llvm/llvm-project/c
[mlir] Fix the names of exported functionsThe names of the functions that are supposed to be exported do not match the implementations. This is due in part to https://github.com/llvm/llvm-project/commit/cac7aabbd8236bef2909bfc0dbba17644f7aaade.This change makes the implementations and declarations match and adds a couple missing declarations.The new names follow the pattern of the existing `verify` functions where the prefix is maintained as `_mlir_ciface_` but the suffix follows the new naming convention.Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D124891
show more ...
[mlir][NFC] Update textual references of `func` to `func.func` in Integration 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
[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][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] 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] Fix integration tests broken by D118285[MLIR] Fix integration tests broken by D118285.
[mlir][MemRef] Deprecate unspecified trailing offset, size, and strides semantics of `OffsetSizeAndStrideOpInterface`.The semantics of the ops that implement the`OffsetSizeAndStrideOpInterface` is
[mlir][MemRef] Deprecate unspecified trailing offset, size, and strides semantics of `OffsetSizeAndStrideOpInterface`.The semantics of the ops that implement the`OffsetSizeAndStrideOpInterface` is that if the number of offsets,sizes or strides are less than the rank of the source, then somedefault values are filled along the trailing dimensions (0 for offset,source dimension of sizes, and 1 for strides). This is confusing,especially with rank-reducing semantics. Immediate issue here is thatthe methods of `OffsetSizeAndStridesOpInterface` assumes that thenumber of values is same as the source rank. This cause out-of-boundserrors.So simplifying the specification of `OffsetSizeAndStridesOpInterface`to make it invalid to specify number of offsets/sizes/strides notequal to the source rank.Differential Revision: https://reviews.llvm.org/D115677
[mlir] Move min/max ops from Std to Arith.Differential Revision: https://reviews.llvm.org/D113881
[mlir](arithmetic) Add ceildivui to the arithmetic dialectThe specific description is [[ https://llvm.discourse.group/t/adding-unsigned-integer-ceil-and-floor-in-std-dialect/4541 | Adding unsigned
[mlir](arithmetic) Add ceildivui to the arithmetic dialectThe specific description is [[ https://llvm.discourse.group/t/adding-unsigned-integer-ceil-and-floor-in-std-dialect/4541 | Adding unsigned integer ceil in Std Dialect ]] .When we lower ceilDivOp this will generate below code, sometimes we know m and n are unsigned intergal.Here are some redundant judgments about positive and negative.So we need to add some unsigned operations to simplify the instructions.```ceilDiv(n, m) x = (m > 0) ? -1 : 1 return (n*m>0) ? ((n+x) / m) + 1 : - (-n / m)```unsigned operations:```ceilDivU(n, m) return n ==0 ? 0 : ((n - 1) / m) + 1```Reviewed By: MogballDifferential Revision: https://reviews.llvm.org/D113363
[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
Fix last leaky MLIR integration test (NFC)
[mlir] Factor type reconciliation out of Standard-to-LLVM conversionConversion to the LLVM dialect is being refactored to be more progressive andis now performed as a series of independent passes
[mlir] Factor type reconciliation out of Standard-to-LLVM conversionConversion to the LLVM dialect is being refactored to be more progressive andis now performed as a series of independent passes converting differentdialects. These passes may produce `unrealized_conversion_cast` operations thatrepresent pending conversions between built-in and LLVM dialect types.Historically, a more monolithic Standard-to-LLVM conversion pass did not needthese casts as all operations were converted in one shot. Previous refactoringshave led to the requirement of running the Standard-to-LLVM conversion pass toclean up `unrealized_conversion_cast`s even though the IR had no standardoperations in it. The pass must have been also run the last among all to-LLVMpasses, in contradiction with the partial conversion logic. Additionally, theway it was set up could produce invalid operations by removing casts betweenLLVM and built-in types even when the consumer did not accept the uncastedtype, or could lead to cryptic conversion errors (recursive application of therewrite pattern on `unrealized_conversion_cast` as a means to indicate failureto eliminate casts).In fact, the need to eliminate A->B->A `unrealized_conversion_cast`s is notspecific to to-LLVM conversions and can be factored out into a separate typereconciliation pass, which is achieved in this commit. While the cast operationitself has a folder pattern, it is insufficient in most conversion passes asthe folder only applies to the second cast. Without complex legality setup inthe conversion target, the conversion infra will either consider the castoperations valid and not fold them (a separate canonicalization would benecessary to trigger the folding), or consider the first cast invalid upongeneration and stop with error. The pattern provided by the reconciliation passapplies to the first cast operation instead. Furthermore, having a separatepass makes it clear when `unrealized_conversion_cast`s could not have beeneliminated since it is the only reason why this pass can fail.Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D109507
[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] 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
Move the MLIR integration tests as a subdirectory of test (NFC)This does not change the behavior directly: the tests only run when`-DMLIR_INCLUDE_INTEGRATION_TESTS=ON` is configured. However runni
Move the MLIR integration tests as a subdirectory of test (NFC)This does not change the behavior directly: the tests only run when`-DMLIR_INCLUDE_INTEGRATION_TESTS=ON` is configured. However running`ninja check-mlir` will not run all the tests within a singlelit invocation. The previous behavior would wait for all the integrationtests to complete before starting to run the first regular test. Thetest results were also reported separately. This change is unifying allof this and allow concurrent execution of the integration tests withregular non-regression and unit-tests.Differential Revision: https://reviews.llvm.org/D97241