[mlir][test] Require JIT support in JIT tests

A number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JIT
support`. This patch fixes that by mimicing `clang/test/lit.cfg.py` which
impl

[mlir][test] Require JIT support in JIT tests

A number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JIT
support`. This patch fixes that by mimicing `clang/test/lit.cfg.py` which
implements a `host-supports-jit` keyword for this. The gtest-based unit
tests don't support `REQUIRES:`, so lack of support needs to be hardcoded
there.

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 tests

I am going to enable MLIR test on msan bot
https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-bootstrap-msan

Reviewed By: ftynse

Differential Revi

[mlir][msan][test] Disable jit tests

I am going to enable MLIR test on msan bot
https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-bootstrap-msan

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D124574

show more ...

[mlir][NFC] Update textual references of `func` to `func.func` in tool/runner tests

The special case parsing of `func` operations is being removed.

[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace

FuncOp has been moved to the `func` namespace for a little over a month, the
using directive can be dropped now.

[mlir] Move the Builtin FuncOp to the Func dialect

This commit moves FuncOp out of the builtin dialect, and into the Func
dialect. This move has been planned in some capacity from the moment
we made

[mlir] Move the Builtin FuncOp to the Func dialect

This commit moves FuncOp out of the builtin dialect, and into the Func
dialect. This move has been planned in some capacity from the moment
we made FuncOp an operation (years ago). This commit handles the
functional aspects of the move, but various aspects are left untouched
to ease migration: func::FuncOp is re-exported into mlir to reduce
the actual API churn, the assembly format still accepts the unqualified
`func`. These temporary measures will remain for a little while to
simplify migration before being removed.

Differential Revision: https://reviews.llvm.org/D121266

show more ...

Update more `parseSourceString()` call sites.

Change to non-deprecated function template (see D121075).

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D121102

[mlir][NFC] Rename StandardToLLVM to FuncToLLVM

The current StandardToLLVM conversion patterns only really handle
the Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, but
those s

[mlir][NFC] Rename StandardToLLVM to FuncToLLVM

The current StandardToLLVM conversion patterns only really handle
the Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, but
those should be/will be split out in a followup. This commit focuses solely
on being an NFC rename.

Aside from the directory change, the pattern and pass creation API have been renamed:
* populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern
* populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns
* createLowerToLLVMPass -> createConvertFuncToLLVMPass

Differential Revision: https://reviews.llvm.org/D120778

show more ...

[mlir][NFC] Move Parser.h to Parser/

There is no reason for this file to be at the top-level, and
its 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, and
its current placement predates the Parser/ folder's existence.

Differential Revision: https://reviews.llvm.org/D121024

show more ...

[mlir] Silence warnings when building with MSVC

Differential Revision: https://reviews.llvm.org/D118536

Replace OwningModuleRef with OwningOpRef<ModuleOp>

This addresses a TODO in BuiltinOps.h.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D118574

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D115956

[MLIR] Replace std ops with arith dialect ops

Precursor: https://reviews.llvm.org/D110200

Removed redundant ops from the standard dialect that were moved to the
`arith` or `math` dialects.

Renamed

[MLIR] Replace std ops with arith dialect ops

Precursor: https://reviews.llvm.org/D110200

Removed 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, jpienaar

Differential Revision: https://reviews.llvm.org/D110797

show more ...

[mlir] Factor type reconciliation out of Standard-to-LLVM conversion

Conversion to the LLVM dialect is being refactored to be more progressive and
is now performed as a series of independent passes

[mlir] Factor type reconciliation out of Standard-to-LLVM conversion

Conversion to the LLVM dialect is being refactored to be more progressive and
is now performed as a series of independent passes converting different
dialects. These passes may produce `unrealized_conversion_cast` operations that
represent pending conversions between built-in and LLVM dialect types.
Historically, a more monolithic Standard-to-LLVM conversion pass did not need
these casts as all operations were converted in one shot. Previous refactorings
have led to the requirement of running the Standard-to-LLVM conversion pass to
clean up `unrealized_conversion_cast`s even though the IR had no standard
operations in it. The pass must have been also run the last among all to-LLVM
passes, in contradiction with the partial conversion logic. Additionally, the
way it was set up could produce invalid operations by removing casts between
LLVM and built-in types even when the consumer did not accept the uncasted
type, or could lead to cryptic conversion errors (recursive application of the
rewrite pattern on `unrealized_conversion_cast` as a means to indicate failure
to eliminate casts).

In fact, the need to eliminate A->B->A `unrealized_conversion_cast`s is not
specific to to-LLVM conversions and can be factored out into a separate type
reconciliation pass, which is achieved in this commit. While the cast operation
itself has a folder pattern, it is insufficient in most conversion passes as
the folder only applies to the second cast. Without complex legality setup in
the conversion target, the conversion infra will either consider the cast
operations valid and not fold them (a separate canonicalization would be
necessary to trigger the folding), or consider the first cast invalid upon
generation and stop with error. The pattern provided by the reconciliation pass
applies to the first cast operation instead. Furthermore, having a separate
pass makes it clear when `unrealized_conversion_cast`s could not have been
eliminated since it is the only reason why this pass can fail.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D109507

show more ...

[mlir] factor memref-to-llvm lowering out of std-to-llvm

After the MemRef has been split out of the Standard dialect, the
conversion to the LLVM dialect remained as a huge monolithic pass.
This is u

[mlir] factor memref-to-llvm lowering out of std-to-llvm

After the MemRef has been split out of the Standard dialect, the
conversion to the LLVM dialect remained as a huge monolithic pass.
This is undesirable for the same complexity management reasons as having
a huge Standard dialect itself, and is even more confusing given the
existence of a separate dialect. Extract the conversion of the MemRef
dialect operations to LLVM into a separate library and a separate
conversion pass.

Reviewed By: herhut, silvas

Differential Revision: https://reviews.llvm.org/D105625

show more ...

[MLIR] Create memref dialect and move dialect-specific ops from std.

Create the memref dialect and move dialect-specific ops
from std dialect to this dialect.

Moved ops:
AllocOp -> MemRef_AllocOp
A

[MLIR] Create memref dialect and move dialect-specific ops from std.

Create the memref dialect and move dialect-specific ops
from std dialect to this dialect.

Moved ops:
AllocOp -> MemRef_AllocOp
AllocaOp -> MemRef_AllocaOp
AssumeAlignmentOp -> MemRef_AssumeAlignmentOp
DeallocOp -> MemRef_DeallocOp
DimOp -> MemRef_DimOp
MemRefCastOp -> MemRef_CastOp
MemRefReinterpretCastOp -> MemRef_ReinterpretCastOp
GetGlobalMemRefOp -> MemRef_GetGlobalOp
GlobalMemRefOp -> MemRef_GlobalOp
LoadOp -> MemRef_LoadOp
PrefetchOp -> MemRef_PrefetchOp
ReshapeOp -> MemRef_ReshapeOp
StoreOp -> MemRef_StoreOp
SubViewOp -> MemRef_SubViewOp
TransposeOp -> MemRef_TransposeOp
TensorLoadOp -> MemRef_TensorLoadOp
TensorStoreOp -> MemRef_TensorStoreOp
TensorToMemRefOp -> MemRef_BufferCastOp
ViewOp -> MemRef_ViewOp

The roadmap to split the memref dialect from std is discussed here:
https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667

Differential Revision: https://reviews.llvm.org/D98041

show more ...

[mlir] make implementations of translation to LLVM IR interfaces private

There is no need for the interface implementations to be exposed, opaque
registration functions are sufficient for all users,

[mlir] make implementations of translation to LLVM IR interfaces private

There is no need for the interface implementations to be exposed, opaque
registration functions are sufficient for all users, similarly to passes.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D97852

show more ...

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.h

Working on a fix.

This reverts commit 8aa6c3765b924d86f623d452777eb76b83bf2787.

show more ...

[MLIR] Create memref dialect and move several dialect-specific ops from std.

Create the memref dialect and move several dialect-specific ops without
dependencies 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 without
dependencies to other ops from std dialect to this dialect.

Moved ops:
AllocOp -> MemRef_AllocOp
AllocaOp -> MemRef_AllocaOp
DeallocOp -> MemRef_DeallocOp
MemRefCastOp -> MemRef_CastOp
GetGlobalMemRefOp -> MemRef_GetGlobalOp
GlobalMemRefOp -> MemRef_GlobalOp
PrefetchOp -> MemRef_PrefetchOp
ReshapeOp -> MemRef_ReshapeOp
StoreOp -> MemRef_StoreOp
TransposeOp -> MemRef_TransposeOp
ViewOp -> MemRef_ViewOp

The roadmap to split the memref dialect from std is discussed here:
https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667

Differential Revision: https://reviews.llvm.org/D96425

show more ...

[mlir] Introduce dialect interfaces for translation to LLVM IR

The existing approach to translation to the LLVM IR relies on a single
translation supporting the base LLVM dialect, extensible through

[mlir] Introduce dialect interfaces for translation to LLVM IR

The existing approach to translation to the LLVM IR relies on a single
translation supporting the base LLVM dialect, extensible through inheritance to
support intrinsic-based dialects also derived from LLVM IR such as NVVM and
AVX512. This approach does not scale well as it requires additional
translations to be created for each new intrinsic-based dialect and does not
allow them to mix in the same module, contrary to the rest of the MLIR
infrastructure. Furthermore, OpenMP translation ingrained itself into the main
translation mechanism.

Start refactoring the translation to LLVM IR to operate using dialect
interfaces. Each dialect that contains ops translatable to LLVM IR can
implement the interface for translating them, and the top-level translation
driver can operate on interfaces without knowing about specific dialects.
Furthermore, the delayed dialect registration mechanism allows one to avoid a
dependency on LLVM IR in the dialect that is translated to it by implementing
the translation as a separate library and only registering it at the client
level.

This change introduces the new mechanism and factors out the translation of the
"main" LLVM dialect. The remaining dialects will follow suit.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D96503

show more ...

Fix StridedMemRefType operator[] SFINAE to allow correctly selecting the `int64_t` overload for non-container operands

Add convenience C++ helper to manipulate ranked strided memref

Reland 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 of
the DialectRegistry APIs in the context. It'll reland shortly after
fixing the API usage.

show more ...

Add convenience C++ helper to manipulate ranked strided memref

Differential 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 argument
wrapped in `ExecutionEngine::Result<T>`, and delegate the packing of
arguments to a trait to allow for customization for some types.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D95961

show more ...