[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] Don't use Optional::getValue (NFC)

Remove unneeded cl::ZeroOrMore for cl::opt/cl::list options

Apply clang-tidy fixes for performance-unnecessary-value-param in JitRunner.cpp (NFC)

Guard copy of std::function to llvm::function_ref (fix crash)

This is a footgun: assigning a null std::function to a function_ref
does not yield a null function_ref...

Use std::function instead of function_ref in MLIR JitRunner

This fixes an ASAN failure.

Reland [mlir] Remove uses of LLVM's legacy pass manager

Use the new pass manager.

This also removes the ability to run arbitrary sets of passes. Not sure if this functionality is used, but it doesn

Reland [mlir] Remove uses of LLVM's legacy pass manager

Use the new pass manager.

This also removes the ability to run arbitrary sets of passes. Not sure if this functionality is used, but it doesn't seem to be tested.

No need to initialize passes outside of constructing the PassBuilder with the new pass manager.

Reland: Fixed custom calls to `-lower-matrix-intrinsics` in integration tests by replacing them with `-O0 -enable-matrix`.

Reviewed By: mehdi_amini

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

show more ...

Revert "[mlir] Remove uses of LLVM's legacy pass manager"

This reverts commit b0f7f6f78d050cc89b31c87fb48744989145af60.

Causes test failures: https://lab.llvm.org/buildbot#builders/61/builds/24879

[mlir] Remove uses of LLVM's legacy pass manager

Use the new pass manager.

This also removes the ability to run arbitrary sets of passes. Not sure if this functionality is used, but it doesn't seem

[mlir] Remove uses of LLVM's legacy pass manager

Use the new pass manager.

This also removes the ability to run arbitrary sets of passes. Not sure if this functionality is used, but it doesn't seem to be tested.

No need to initialize passes outside of constructing the PassBuilder with the new pass manager.

Reviewed By: mehdi_amini

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

show more ...

[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"

This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes

[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"

This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes it
clear what the intent is (i.e. to represent the type of the function).

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

show more ...

[mlir] ExecutionEngine: default enableObjectCache to false

The enableObjectCache option was added in
https://reviews.llvm.org/rG06e8101034e, defaulting to false. However,
the init code added there g

[mlir] ExecutionEngine: default enableObjectCache to false

The enableObjectCache option was added in
https://reviews.llvm.org/rG06e8101034e, defaulting to false. However,
the init code added there got its logic reversed
(cache(enableObjectCache ? nullptr : new SimpleObjectCache()), which was
fixed in https://reviews.llvm.org/rGd1186fcb04 by setting the default to
true, thereby preserving the existing behavior even if it was
unintentional.

Default now the object cache to false as it was originally intended.
While at it, mention in enableObjectCache's documentation how the
cache can be dumped.

Reviewed-by: mehdi_amini
Differential Revision: https://reviews.llvm.org/D121291

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] Change call sites from deprecated `parseSourceFile()` to `parseSourceFile<ModuleOp>()`.

Mark `parseSourceFile()` deprecated. The functions will be removed two weeks after landing this change.

[MLIR] Change call sites from deprecated `parseSourceFile()` to `parseSourceFile<ModuleOp>()`.

Mark `parseSourceFile()` deprecated. The functions will be removed two weeks after landing this change.

Reviewed By: rriddle

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

show more ...

[mlir][NFC] Use options struct in ExecutionEngine::create

Its number of optional parameters has grown too large,
which makes adding new optional parameters quite a chore.

Fix this by using an optio

[mlir][NFC] Use options struct in ExecutionEngine::create

Its number of optional parameters has grown too large,
which makes adding new optional parameters quite a chore.

Fix this by using an options struct.

Reviewed By: mehdi_amini

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

show more ...

Replace OwningModuleRef with OwningOpRef<ModuleOp>

This addresses a TODO in BuiltinOps.h.

Reviewed By: rriddle

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

[mlir][NFC] Add a using for llvm::SMLoc/llvm::SMRange to LLVM.h

These are used pervasively during parsing.

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

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

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

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

Differenti

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

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

show more ...

Rename MlirExecutionEngine lookup to lookupPacked

The purpose of the change is to make clear whether the user is
retrieving the original function or the wrapper function, in line with
the invoke com

Rename MlirExecutionEngine lookup to lookupPacked

The purpose of the change is to make clear whether the user is
retrieving the original function or the wrapper function, in line with
the invoke commands. This new functionality is useful for users that
already have defined their own packed interface, so they do not want the
extra layer of indirection, or for users wanting to the look at the
resulting primary function rather than the wrapper function.

All locations, except the python bindings now have a `lookupPacked`
method that matches the original `lookup` functionality. `lookup`
still exists, but with new semantics.

- `lookup` returns the function with a given name. If `bool f(int,int)`
is compiled, `lookup` will return a reference to `bool(*f)(int,int)`.
- `lookupPacked` returns the packed wrapper of the function with the
given name. If `bool f(int,int)` is compiled, `lookupPacked` will return
`void(*mlir_f)(void**)`.

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

show more ...

[mlir] Load dynamic libraries in JitRunner from absolute paths so that GDB can find the symbol tables.

Reviewed By: mehdi_amini, ftynse

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

[mlir] Make JitRunnerMain main take a DialectRegistry

Historically, JitRunner has been registering all available dialects with the
context and depending on them without the real need. Make it take a

[mlir] Make JitRunnerMain main take a DialectRegistry

Historically, JitRunner has been registering all available dialects with the
context and depending on them without the real need. Make it take a registry
that contains only the dialects that are expected in the input and stop linking
in all dialects.

Reviewed By: mehdi_amini

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

show more ...

[mlir] avoid exposing mutable DialectRegistry from MLIRContext

MLIRContext allows its users to access directly to the DialectRegistry it
contains. While sometimes useful for registering additional d

[mlir] avoid exposing mutable DialectRegistry from MLIRContext

MLIRContext allows its users to access directly to the DialectRegistry it
contains. While sometimes useful for registering additional dialects on an
already existing context, this breaks the encapsulation by essentially giving
raw accesses to a part of the context's internal state. Remove this mutable
access and instead provide a method to append a given DialectRegistry to the
one already contained in the context. Also provide a shortcut mechanism to
construct a context from an already existing registry, which seems to be a
common use case in the wild. Keep read-only access to the registry contained in
the context in case it needs to be copied or used for constructing another
context.

With this change, DialectRegistry is no longer concerned with loading the
dialects and deciding whether to invoke delayed interface registration. Loading
is concentrated in the MLIRContext, and the functionality of the registry
better reflects its name.

Depends On D96137

Reviewed By: mehdi_amini

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

show more ...

[mlir:JitRunner] Use custom shared library init/destroy functions if available

Use custom mlir runner init/destroy functions to safely init and destroy shared libraries loaded by the JitRunner.

Thi

[mlir:JitRunner] Use custom shared library init/destroy functions if available

Use custom mlir runner init/destroy functions to safely init and destroy shared libraries loaded by the JitRunner.

This mechanism is ignored for Windows builds (for now) because init/destroy functions are not exported, and library unloading relies on static destructors.

Re-submit https://reviews.llvm.org/D94270 with a temporary workaround for windows

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

show more ...

[mlir] replace LLVM dialect float types with built-ins

Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their

[mlir] replace LLVM dialect float types with built-ins

Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their built-in
counterparts. At the API level, this is a direct replacement. At the syntax
level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively,
to be compatible with the built-in type syntax. The old keywords can still be
parsed but produce a deprecation warning and will be eventually removed.

Depends On D94178

Reviewed By: mehdi_amini, silvas, antiagainst

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

show more ...

Revert "[mlir:JitRunner] Use custom shared library init/destroy functions if available"

This reverts commit 84dc9b451bfd62474f44dd1af0e4955a0110d523.

Fix Windows breakage: http://lab.llvm.org:8011/

Revert "[mlir:JitRunner] Use custom shared library init/destroy functions if available"

This reverts commit 84dc9b451bfd62474f44dd1af0e4955a0110d523.

Fix Windows breakage: http://lab.llvm.org:8011/#/builders/13/builds/3658/steps/6/logs/stdio

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

show more ...