#
047e8e47 |
| 22-Jan-2025 |
Michał Górny <mgorny@gentoo.org> |
Reapply "[mlir] Link libraries that aren't included in libMLIR to libMLIR" (#123910)
Use `mlir_target_link_libraries()` to link dependencies of libraries
that are not included in libMLIR, to ensure
Reapply "[mlir] Link libraries that aren't included in libMLIR to libMLIR" (#123910)
Use `mlir_target_link_libraries()` to link dependencies of libraries
that are not included in libMLIR, to ensure that they link to the dylib
when they are used in Flang. Otherwise, they implicitly pull in all
their static dependencies, effectively causing Flang binaries to
simultaneously link to the dylib and to static libraries, which is never
a good idea.
I have only covered the libraries that are used by Flang. If you wish, I
can extend this approach to all non-libMLIR libraries in MLIR, making
MLIR itself also link to the dylib consistently.
[v3 with more `-DBUILD_SHARED_LIBS=ON` fixes]
show more ...
|
#
9decc24c |
| 22-Jan-2025 |
Michał Górny <mgorny@gentoo.org> |
Revert "[mlir] Link libraries that aren't included in libMLIR to libMLIR (#123781)"
This reverts commit 4c6242ebf50dde0597df2bace49d534b61122496. More BUILD_SHARED_LIBS=ON regressions, sigh.
|
#
4c6242eb |
| 22-Jan-2025 |
Michał Górny <mgorny@gentoo.org> |
[mlir] Link libraries that aren't included in libMLIR to libMLIR (#123781)
Use `mlir_target_link_libraries()` to link dependencies of libraries
that are not included in libMLIR, to ensure that they
[mlir] Link libraries that aren't included in libMLIR to libMLIR (#123781)
Use `mlir_target_link_libraries()` to link dependencies of libraries
that are not included in libMLIR, to ensure that they link to the dylib
when they are used in Flang. Otherwise, they implicitly pull in all
their static dependencies, effectively causing Flang binaries to
simultaneously link to the dylib and to static libraries, which is never
a good idea.
I have only covered the libraries that are used by Flang. If you wish, I
can extend this approach to all non-libMLIR libraries in MLIR, making
MLIR itself also link to the dylib consistently.
[v2 with fixed `-DBUILD_SHARED_LIBS=ON` build]
show more ...
|
#
e7e3c45b |
| 21-Jan-2025 |
Andrea Faulds <andrea.faulds@amd.com> |
[mlir] Remove mlir-vulkan-runner and GPUToVulkan conversion passes (#123750)
This follows up on 733be4ed7dcf976719f424c0cb81b77a14f91f5a, which made
mlir-vulkan-runner and its associated passes red
[mlir] Remove mlir-vulkan-runner and GPUToVulkan conversion passes (#123750)
This follows up on 733be4ed7dcf976719f424c0cb81b77a14f91f5a, which made
mlir-vulkan-runner and its associated passes redundant, and completes
the main goal of #73457. The mlir-vulkan-runner tests become part of the
integration test suite, and the Vulkan runner runtime components become
part of ExecutionEngine, just as was done when removing other
target-specific runners.
show more ...
|
#
8b879d10 |
| 20-Jan-2025 |
Michał Górny <mgorny@gentoo.org> |
Revert "[mlir] Link libraries that aren't included in libMLIR to libMLIR (#123477)"
This reverts commit af6616676fb7f9dd4898290ea684ee0c90f1701d. It broke builds with `-DBUILD_SHARED_LIBS=ON`.
|
#
af661667 |
| 20-Jan-2025 |
Michał Górny <mgorny@gentoo.org> |
[mlir] Link libraries that aren't included in libMLIR to libMLIR (#123477)
Use `mlir_target_link_libraries()` to link dependencies of libraries
that are not included in libMLIR, to ensure that they
[mlir] Link libraries that aren't included in libMLIR to libMLIR (#123477)
Use `mlir_target_link_libraries()` to link dependencies of libraries
that are not included in libMLIR, to ensure that they link to the dylib
when they are used in Flang. Otherwise, they implicitly pull in all
their static dependencies, effectively causing Flang binaries to
simultaneously link to the dylib and to static libraries, which is never
a good idea.
I have only covered the libraries that are used by Flang. If you wish, I
can extend this approach to all non-libMLIR libraries in MLIR, making
MLIR itself also link to the dylib consistently.
show more ...
|
#
0e39b134 |
| 08-Nov-2024 |
Andrea Faulds <andrea.faulds@amd.com> |
[mlir] Remove the mlir-spirv-cpu-runner (move to mlir-cpu-runner) (#114563)
This commit builds on and completes the work done in
9f6c632ecda08bfff76b798c46d5d7cfde57b5e9 to eliminate the need for a
[mlir] Remove the mlir-spirv-cpu-runner (move to mlir-cpu-runner) (#114563)
This commit builds on and completes the work done in
9f6c632ecda08bfff76b798c46d5d7cfde57b5e9 to eliminate the need for a
separate mlir-spirv-cpu-runner binary. Since the MLIR processing is
already done outside this runner, the only real difference between it
and the mlir-cpu-runner is the final linking step between the nested
LLVM IR modules. By moving this step into mlir-cpu-runner behind a new
command-line flag (`--link-nested-modules`), this commit is able to
completely remove the runner component of the mlir-spirv-cpu-runner.
The runtime libraries and the tests are moved and renamed to fit into
the Execution Engine and Integration tests, following the model of the
similar migration done for the CUDA Runner in D97463.
show more ...
|
#
74e1062e |
| 09-Oct-2024 |
Zentrik <llvm.zentrik@gmail.com> |
[MLIR] Don't build MLIRExecutionEngineShared on Windows (#109524)
This disabled the build of `MLIRExecutionEngineShared` because this causes linkage issues in windows for currently unknown reasons.
[MLIR] Don't build MLIRExecutionEngineShared on Windows (#109524)
This disabled the build of `MLIRExecutionEngineShared` because this causes linkage issues in windows for currently unknown reasons.
Related issue: https://github.com/llvm/llvm-project/issues/106859.
show more ...
|
#
631ae59d |
| 30-Mar-2024 |
Christian Ulmann <christianulmann@gmail.com> |
[MLIR][ExecutionEngine] Introduce shared library (#87067)
This commit introduces a shared library for the MLIR execution engine.
This library is only built when `LLVM_BUILD_LLVM_DYLIB` is set. Havi
[MLIR][ExecutionEngine] Introduce shared library (#87067)
This commit introduces a shared library for the MLIR execution engine.
This library is only built when `LLVM_BUILD_LLVM_DYLIB` is set. Having
such a library allows downstream users to depend on the execution engine
without giving up dynamic linkage. This is especially important for CPU
runner-style tools, as they link against large parts of MLIR and LLVM.
It is alternatively possible to modify the `MLIRExecutionEngine` target
when `LLVM_BUILD_LLVM_DYLIB` is set, to avoid duplicated libraries.
show more ...
|
#
e280c287 |
| 22-Jan-2024 |
Benjamin Maxwell <benjamin.maxwell@arm.com> |
[mlir] Add `mlir_arm_runner_utils` library for use in integration tests (#78583)
This adds a new `mlir_arm_runner_utils` library that contains utils
specific to Arm/AArch64. This is for use in MLIR
[mlir] Add `mlir_arm_runner_utils` library for use in integration tests (#78583)
This adds a new `mlir_arm_runner_utils` library that contains utils
specific to Arm/AArch64. This is for use in MLIR integration tests.
This initial patch adds `setArmVLBits()` and `setArmSVLBits()`. This
allows changing vector length or streaming vector length at runtime (or
setting it to a known minimum, i.e. 128-bits).
show more ...
|
#
7bc6c4ab |
| 14-Dec-2023 |
Yinying Li <107574043+yinying-lisa-li@users.noreply.github.com> |
[mlir][print]Add functions for printing memref f16/bf16/i16 (#75094)
1. Added functions for printMemrefI16/f16/bf16.
2. Added a new integration test for all the printMemref functions.
|
#
0bda20b8 |
| 23-Nov-2023 |
Ivan Butygin <ivan.butygin@gmail.com> |
Reland [mlir] Workaround for export lib generation on Windows for mlir_arm_sme_abi_stubs #73147 (#73238)
https://github.com/llvm/llvm-project/pull/73147
Fixed the visibility macro
|
#
bf353a71 |
| 23-Nov-2023 |
Ivan Butygin <ivan.butygin@gmail.com> |
Revert "[mlir] Workaround for export lib generation on Windows for `mlir_arm_sme_abi_stubs` (#73147)"
This reverts commit 6248c24876d81d83544af02399d46813dbea869c.
broke the bots
|
#
6248c248 |
| 23-Nov-2023 |
Ivan Butygin <ivan.butygin@gmail.com> |
[mlir] Workaround for export lib generation on Windows for `mlir_arm_sme_abi_stubs` (#73147)
Using mlir cmake in downstream project fails with error
```
CMake Error at D:/projs/llvm/llvm-install/l
[mlir] Workaround for export lib generation on Windows for `mlir_arm_sme_abi_stubs` (#73147)
Using mlir cmake in downstream project fails with error
```
CMake Error at D:/projs/llvm/llvm-install/lib/cmake/mlir/MLIRTargets.cmake:2537 (message):
The imported target "mlir_arm_sme_abi_stubs" references the file
"D:/projs/llvm/llvm-install/lib/mlir_arm_sme_abi_stubs.lib"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"D:/projs/llvm/llvm-install/lib/cmake/mlir/MLIRTargets.cmake"
but not all the files it references.
Call Stack (most recent call first):
D:/projs/llvm/llvm-install/lib/cmake/mlir/MLIRConfig.cmake:37 (include)
mlir/CMakeLists.txt:5 (find_package)
```
Windows cmake needs export libaries but it seems they are only being
generated if you have at least one exported symbol.
Add export attributes to symbols.
Not sure what the best approach to fix this (probably we should just
disable this lib on windows entirely), but it fixed things for me
locally.
show more ...
|
#
783ac3b6 |
| 14-Nov-2023 |
Benjamin Maxwell <benjamin.maxwell@arm.com> |
[mlir][ArmSME] Make use of backend function attributes for enabling ZA storage (#71044)
Previously, we were inserting za.enable/disable intrinsics for functions
with the "arm_za" attribute (at the
[mlir][ArmSME] Make use of backend function attributes for enabling ZA storage (#71044)
Previously, we were inserting za.enable/disable intrinsics for functions
with the "arm_za" attribute (at the MLIR level), rather than using the
backend attributes. This was done to avoid a dependency on the SME ABI
functions from compiler-rt (which have only recently been implemented).
Doing things this way did have correctness issues, for example, calling
a streaming-mode function from another streaming-mode function (both
with ZA enabled) would lead to ZA being disabled after returning to the
caller (where it should still be enabled). Fixing issues like this would
require re-doing the ABI work already done in the backend within MLIR.
Instead, this patch switches to use the "arm_new_za" (backend) attribute
for enabling ZA for an MLIR function. For the integration tests, this
requires some way of linking the SME ABI functions. This is done via the
`%arm_sme_abi_shlib` lit substitution. By default, this expands to a
stub implementation of the SME ABI functions, but this can be overridden
by providing the `ARM_SME_ABI_ROUTINES_SHLIB` CMake cache variable
(pointing it at an alternative implementation). For now, the ArmSME
integration tests pass with just stubs, as we don't make use of nested
ZA-enabled calls.
A future patch may add an option to compiler-rt to build the SME
builtins into a standalone shared library to allow easily
building/testing with the actual implementation.
show more ...
|
#
7fa19e6f |
| 26-Oct-2023 |
Nishant Patel <nishant.b.patel@intel.com> |
[MLIR] Add SyclRuntimeWrapper (#69648)
|
#
2f8d8c78 |
| 02-Aug-2023 |
Krzysztof Drewniak <Krzysztof.Drewniak@amd.com> |
Generalize finding the rocm_agent_enumberator program
On Fedora, rocminfo is a fedora package and rocm_agent_enumberator is installed to /usr/bin. This causes this error when building.
CMake Error
Generalize finding the rocm_agent_enumberator program
On Fedora, rocminfo is a fedora package and rocm_agent_enumberator is installed to /usr/bin. This causes this error when building.
CMake Error at external/llvm-project/mlir/lib/ExecutionEngine/CMakeLists.txt:232 (message): Could not run rocm_agent_enumerator and ROCM_TEST_CHIPSET is not defined
So use find_program() to look for rocm_agent_enumerator instead of assuming a single location.
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed By: krzysz00
Differential Revision: https://reviews.llvm.org/D156826
show more ...
|
#
3c3ebebc |
| 21-Jun-2023 |
Mitch Phillips <31459023+hctim@users.noreply.github.com> |
Revert "[mlir][RunnerUtils] Make symbols private + implement loading mechanism."
This reverts commit bba2b656110209a3d9863b92c060082479b06ab1.
Reason: Broke the HWASan buildbot. See https://reviews
Revert "[mlir][RunnerUtils] Make symbols private + implement loading mechanism."
This reverts commit bba2b656110209a3d9863b92c060082479b06ab1.
Reason: Broke the HWASan buildbot. See https://reviews.llvm.org/D153250 for more information.
show more ...
|
#
7b4ea67f |
| 21-Jun-2023 |
Mehdi Amini <joker.eph@gmail.com> |
Revert "[mlir][CRunnerUtils] Use explicit execution engine symbol registration."
This reverts commit 9119325a5666e557a19f38a05525578b556c215b.
A buildbot is broken, probably because of this change
Revert "[mlir][CRunnerUtils] Use explicit execution engine symbol registration."
This reverts commit 9119325a5666e557a19f38a05525578b556c215b.
A buildbot is broken, probably because of this change breaking the SHARED_LIBS=ON build more.
show more ...
|
#
9119325a |
| 20-Jun-2023 |
Ingo Müller <ingomueller@google.com> |
[mlir][CRunnerUtils] Use explicit execution engine symbol registration.
As a follow up of https://reviews.llvm.org/D153250, this path uses the explicit symbol registration mechanism of the execution
[mlir][CRunnerUtils] Use explicit execution engine symbol registration.
As a follow up of https://reviews.llvm.org/D153250, this path uses the explicit symbol registration mechanism of the execution engine in the CRunnerUtils library.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D153354
show more ...
|
#
bba2b656 |
| 19-Jun-2023 |
Ingo Müller <ingomueller@google.com> |
[mlir][RunnerUtils] Make symbols private + implement loading mechanism.
There are two ways to make symbols from a shared library visible in the execution engine: exporting the symbols with public vi
[mlir][RunnerUtils] Make symbols private + implement loading mechanism.
There are two ways to make symbols from a shared library visible in the execution engine: exporting the symbols with public visibility or implementing a loading/unloading mechansim that registers the exported symbols explicitly. The latter has only been available in the JIT runner until recently, but https://reviews.llvm.org/D153029 makes it available in any usage of the execution engine (including the Python bindings).
This patch makes the runner utils library use the latter mechanism instead of the former, i.e., it makes all of its symbols private and implements the init/destroy functions of the loading mechanism to control explicitly which symbols it registers.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D153250
show more ...
|
#
50db4789 |
| 07-Jun-2023 |
Aart Bik <ajcbik@google.com> |
[mlir][sparse][gpu] refined build setup for cusparse
Reviewed By: K-Wu
Differential Revision: https://reviews.llvm.org/D152387
|
#
8ed59c53 |
| 06-Jun-2023 |
Kun Wu <kunww@google.com> |
[mlir][sparse][gpu] add sm8.0+ tensor core 2:4 sparsity support
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D151775
|
#
53a5c3ab |
| 05-Jun-2023 |
Mehdi Amini <joker.eph@gmail.com> |
Fix MLIR build with Shared lib enabled
db7cc0348c9a0 added OpenMP support to the execution engine but didn't add the explicit CMake dependency.
|
#
b936816f |
| 29-May-2023 |
Mehdi Amini <joker.eph@gmail.com> |
MLIR/Cuda: Add the appropriate "HINTS" on CMake find_library and mark these REQUIRED
The cmake logic to find cuda paths exposes some paths to search for the cuda library, we need to propagate this t
MLIR/Cuda: Add the appropriate "HINTS" on CMake find_library and mark these REQUIRED
The cmake logic to find cuda paths exposes some paths to search for the cuda library, we need to propagate this through the call for find_library. This was already done for cuSparse but not for cuda.
Differential Revision: https://reviews.llvm.org/D151645
show more ...
|