[mlir][test] Require JIT support in JIT testsA number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JITsupport`. This patch fixes that by mimicing `clang/test/lit.cfg.py` whichimpl
[mlir][test] Require JIT support in JIT testsA number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JITsupport`. This patch fixes that by mimicing `clang/test/lit.cfg.py` whichimplements a `host-supports-jit` keyword for this. The gtest-based unittests don't support `REQUIRES:`, so lack of support needs to be hardcodedthere.Tested on `amd64-pc-solaris2.11` (`check-mlir` results unchanged) and`sparcv9-sun-solaris2.11` (only one unrelated failure left).Differential Revision: https://reviews.llvm.org/D131151(cherry picked from commit ca98e0dd6cf59907f07201c4282dcafeeea11a91)
show more ...
[mlir][msan][test] Disable jit testsI am going to enable MLIR test on msan bothttps://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-bootstrap-msanReviewed By: ftynseDifferential Revi
[mlir][msan][test] Disable jit testsI am going to enable MLIR test on msan bothttps://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-bootstrap-msanReviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D124574
[mlir][NFC] Update textual references of `func` to `func.func` in tool/runner testsThe special case parsing of `func` operations is being removed.
[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
Update more `parseSourceString()` call sites.Change to non-deprecated function template (see D121075).Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D121102
[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][NFC] Move Parser.h to Parser/There is no reason for this file to be at the top-level, andits current placement predates the Parser/ folder's existence.Differential Revision: https://revie
[mlir][NFC] Move Parser.h to Parser/There is no reason for this file to be at the top-level, andits current placement predates the Parser/ folder's existence.Differential Revision: https://reviews.llvm.org/D121024
[mlir] Silence warnings when building with MSVCDifferential Revision: https://reviews.llvm.org/D118536
Replace OwningModuleRef with OwningOpRef<ModuleOp>This addresses a TODO in BuiltinOps.h.Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D118574
Fix clang-tidy issues in mlir/ (NFC)Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D115956
[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
[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
[mlir] make implementations of translation to LLVM IR interfaces privateThere is no need for the interface implementations to be exposed, opaqueregistration functions are sufficient for all users,
[mlir] make implementations of translation to LLVM IR interfaces privateThere is no need for the interface implementations to be exposed, opaqueregistration functions are sufficient for all users, similarly to passes.Reviewed By: mehdi_aminiDifferential Revision: https://reviews.llvm.org/D97852
Revert "[MLIR] Create memref dialect and move several dialect-specific ops from std."This commit introduced a cyclic dependency:Memref dialect depends on Standard because it used ConstantIndexOp.
Revert "[MLIR] Create memref dialect and move several dialect-specific ops from std."This commit introduced a cyclic dependency:Memref dialect depends on Standard because it used ConstantIndexOp.Std depends on the MemRef dialect in its EDSC/Intrinsics.hWorking on a fix.This reverts commit 8aa6c3765b924d86f623d452777eb76b83bf2787.
[MLIR] Create memref dialect and move several dialect-specific ops from std.Create the memref dialect and move several dialect-specific ops withoutdependencies to other ops from std dialect to thi
[MLIR] Create memref dialect and move several dialect-specific ops from std.Create the memref dialect and move several dialect-specific ops withoutdependencies to other ops from std dialect to this dialect.Moved ops:AllocOp -> MemRef_AllocOpAllocaOp -> MemRef_AllocaOpDeallocOp -> MemRef_DeallocOpMemRefCastOp -> MemRef_CastOpGetGlobalMemRefOp -> MemRef_GetGlobalOpGlobalMemRefOp -> MemRef_GlobalOpPrefetchOp -> MemRef_PrefetchOpReshapeOp -> MemRef_ReshapeOpStoreOp -> MemRef_StoreOpTransposeOp -> MemRef_TransposeOpViewOp -> 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/D96425
[mlir] Introduce dialect interfaces for translation to LLVM IRThe existing approach to translation to the LLVM IR relies on a singletranslation supporting the base LLVM dialect, extensible through
[mlir] Introduce dialect interfaces for translation to LLVM IRThe existing approach to translation to the LLVM IR relies on a singletranslation supporting the base LLVM dialect, extensible through inheritance tosupport intrinsic-based dialects also derived from LLVM IR such as NVVM andAVX512. This approach does not scale well as it requires additionaltranslations to be created for each new intrinsic-based dialect and does notallow them to mix in the same module, contrary to the rest of the MLIRinfrastructure. Furthermore, OpenMP translation ingrained itself into the maintranslation mechanism.Start refactoring the translation to LLVM IR to operate using dialectinterfaces. Each dialect that contains ops translatable to LLVM IR canimplement the interface for translating them, and the top-level translationdriver can operate on interfaces without knowing about specific dialects.Furthermore, the delayed dialect registration mechanism allows one to avoid adependency on LLVM IR in the dialect that is translated to it by implementingthe translation as a separate library and only registering it at the clientlevel.This change introduces the new mechanism and factors out the translation of the"main" LLVM dialect. The remaining dialects will follow suit.Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D96503
Fix StridedMemRefType operator[] SFINAE to allow correctly selecting the `int64_t` overload for non-container operands
Add convenience C++ helper to manipulate ranked strided memrefReland 11f32a41c21 that was reverted in e49967fbd90 after fixing the build.Differential Revision: https://reviews.llvm.org/D96192
Revert "Add convenience C++ helper to manipulate ranked strided memref"This reverts commit 11f32a41c2144aeec80d1dce8cc6908fa91794a3.The build is broken because this commit conflits with the refac
Revert "Add convenience C++ helper to manipulate ranked strided memref"This reverts commit 11f32a41c2144aeec80d1dce8cc6908fa91794a3.The build is broken because this commit conflits with the refactoring ofthe DialectRegistry APIs in the context. It'll reland shortly afterfixing the API usage.
Add convenience C++ helper to manipulate ranked strided memrefDifferential Revision: https://reviews.llvm.org/D96192
Rework ExecutionEngine::invoke() to make it more friendly to use from C++This new invoke will pack a list of argument before calling the`invokePacked` method. It accepts returned value as output a
Rework ExecutionEngine::invoke() to make it more friendly to use from C++This new invoke will pack a list of argument before calling the`invokePacked` method. It accepts returned value as output argumentwrapped in `ExecutionEngine::Result<T>`, and delegate the packing ofarguments to a trait to allow for customization for some types.Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D95961