[mlir] Don't use Optional::getValue (NFC)

[mlir:ExecutionEngine] Update use of getAddress now that lookup returns ExecutorAddr

This was changed in 16dcbb53dc7968a3752661aac731172ebe0faf64

[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] Add sectionMemoryMapper to ExecutionEngineOptions

By specifying a sectionMemoryMapper, users can control how
memory for JIT code is allocated.

In particular, I need this in order to use a na

[mlir] Add sectionMemoryMapper to ExecutionEngineOptions

By specifying a sectionMemoryMapper, users can control how
memory for JIT code is allocated.

In particular, I need this in order to use a named memory
region so that profilers such as perf(1) can correctly label
execution cycles coming from JIT'ed code.

Reviewed-by: ezhulenev

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

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

[mlir] Add CMake flags to properly enable Jit event listeners.

By default, the listeners do nothing unless linked in.
This revision allows the "Perf" and "Intel" Jit event listeners to be used.

The

[mlir] Add CMake flags to properly enable Jit event listeners.

By default, the listeners do nothing unless linked in.
This revision allows the "Perf" and "Intel" Jit event listeners to be used.

The "OProfile" event listener is not enabled at this time,
the associated library structure is not well-isolated.

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

show more ...

[mlir] NFC - Format ExecutionEngine.cpp

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

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

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

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

[ExecutionEngine] Fix GEP type

Fix bug introduced in 2c68ecccc9ee1fb37eca318a9b3572813a137cd5,
the GEP type was off-by-ptr. Apparently I didn't run the MLIR
tests.

[OpaquePtr] Remove uses of CreateGEP() without element type

Remove uses of to-be-deprecated API. In cases where the correct
element type was not immediately obvious to me, fall back to
explicit getP

[OpaquePtr] Remove uses of CreateGEP() without element type

Remove uses of to-be-deprecated API. In cases where the correct
element type was not immediately obvious to me, fall back to
explicit getPointerElementType().

show more ...

[mlir] Remove uses of type-less CreateLoad() APIs (NFC)

For the use in LLVMOps.td I used the getPointerElementType()
escape hatch, as it's not obvious to me how the load type
should be properly obta

[mlir] Remove uses of type-less CreateLoad() APIs (NFC)

For the use in LLVMOps.td I used the getPointerElementType()
escape hatch, as it's not obvious to me how the load type
should be properly obtained here.

show more ...

[mlir] ExecutionEngine needs special handling for COFF binaries

Reviewed By: mehdi_amini

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

[mlir] Simplify ModuleTranslation for LLVM IR

A series of preceding patches changed the mechanism for translating MLIR to
LLVM IR to use dialect interface with delayed registration. It is no longer

[mlir] Simplify ModuleTranslation for LLVM IR

A series of preceding patches changed the mechanism for translating MLIR to
LLVM IR to use dialect interface with delayed registration. It is no longer
necessary for specific dialects to derive from ModuleTranslation. Remove all
virtual methods from ModuleTranslation and factor out the entry point to be a
free function.

Also perform some cleanups in ModuleTranslation internals.

Depends On D96774

Reviewed By: nicolasvasilache

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

show more ...

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

[llvm][clang][mlir] Add checks for the return values from Target::createXXX to prevent protential null deref

All these potential null pointer dereferences are reported by my static analyzer for null

[llvm][clang][mlir] Add checks for the return values from Target::createXXX to prevent protential null deref

All these potential null pointer dereferences are reported by my static analyzer for null smart pointer dereferences, which has a different implementation from `alpha.cplusplus.SmartPtr`.

The checked pointers in this patch are initialized by Target::createXXX functions. When the creator function pointer is not correctly set, a null pointer will be returned, or the creator function may originally return a null pointer.

Some of them may not make sense as they may be checked before entering the function, but I fixed them all in this patch. I submit this fix because 1) similar checks are found in some other places in the LLVM codebase for the same return value of the function; and, 2) some of the pointers are dereferenced before they are checked, which may definitely trigger a null pointer dereference if the return value is nullptr.

Reviewed By: tejohnson, MaskRay, jpienaar

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

show more ...

[mlir][BuiltinDialect] Resolve comments from D91571

* Move ops to a BuiltinOps.h
* Add file comments

[mlir][NFC] Remove references to Module.h and Function.h

These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.

Differential Revisi

[mlir][NFC] Remove references to Module.h and Function.h

These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.

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

show more ...

[MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype

This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
proto

[MLIR][mlir-spirv-cpu-runner] A SPIR-V cpu runner prototype

This patch introduces a SPIR-V runner. The aim is to run a gpu
kernel on a CPU via GPU -> SPIRV -> LLVM conversions. This is a first
prototype, so more features will be added in due time.

- Overview
The runner follows similar flow as the other runners in-tree. However,
having converted the kernel to SPIR-V, we encode the bind attributes of
global variables that represent kernel arguments. Then SPIR-V module is
converted to LLVM. On the host side, we emulate passing the data to device
by creating in main module globals with the same symbolic name as in kernel
module. These global variables are later linked with ones from the nested
module. We copy data from kernel arguments to globals, call the kernel
function from nested module and then copy the data back.

- Current state
At the moment, the runner is capable of running 2 modules, nested one in
another. The kernel module must contain exactly one kernel function. Also,
the runner supports rank 1 integer memref types as arguments (to be scaled).

- Enhancement of JitRunner and ExecutionEngine
To translate nested modules to LLVM IR, JitRunner and ExecutionEngine were
altered to take an optional (default to `nullptr`) function reference that
is a custom LLVM IR module builder. This allows to customize LLVM IR module
creation from MLIR modules.

Reviewed By: ftynse, mravishankar

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

show more ...

Preserve the error message when MemoryBuffer creation fails

Reviewed By: mehdi_amini

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

[mlir] take LLVMContext in MLIR-to-LLVM-IR translation

Due to the original type system implementation, LLVMDialect in MLIR contains an
LLVMContext in which the relevant objects (types, metadata) are

[mlir] take LLVMContext in MLIR-to-LLVM-IR translation

Due to the original type system implementation, LLVMDialect in MLIR contains an
LLVMContext in which the relevant objects (types, metadata) are created. When
an MLIR module using the LLVM dialect (and related intrinsic-based dialects
NVVM, ROCDL, AVX512) is converted to LLVM IR, it could only live in the
LLVMContext owned by the dialect. The type system no longer relies on the
LLVMContext, so this limitation can be removed. Instead, translation functions
now take a reference to an LLVMContext in which the LLVM IR module should be
constructed. The caller of the translation functions is responsible for
ensuring the same LLVMContext is not used concurrently as the translation no
longer uses a dialect-wide context lock.

As an additional bonus, this change removes the need to recreate the LLVM IR
module in a different LLVMContext through printing and parsing back, decreasing
the compilation overhead in JIT and GPU-kernel-to-blob passes.

Reviewed By: rriddle, mehdi_amini

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

show more ...

[mlir][NFC] Remove usernames and google bug numbers from TODO comments.

These were largely leftover from when MLIR was a google project, and don't really follow LLVM guidelines.

[mlir][SystemZ] Fix incompatible datalayout in SystemZ

MLIR tests in "mlir/test/mlir-cpu-runner" fails in SystemZ (z14) because
of incompatible datalayout error. This patch fixes it by setting host

[mlir][SystemZ] Fix incompatible datalayout in SystemZ

MLIR tests in "mlir/test/mlir-cpu-runner" fails in SystemZ (z14) because
of incompatible datalayout error. This patch fixes it by setting host
CPU name in createTargetMachine()

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

show more ...

[MLIR] Add symbol map to mlir ExecutionEngine

Add additional symbol mapping to be able to provide custom symbols to jitted code at runtime.

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