[Libomptarget] Allow the CPU targets to be built without libffi #77495
Conversation
jhuber6
requested review from
carlobertolli,
jdoerfert,
JonChesterfield,
jplehr,
ronlieb,
saiislam and
uweigand
|
Is there a way to add a test for this? Or is it covered by existing tests? |
It's covered by the existing x64 tests, but you need to force it to use the dlopened path. I did that and it's good on my x64 system. Could check on ppc if really needed, but it would take like a full day to build on Summit. |
Does the test suite have a test where it forces the use of the dlopened path? |
No, this is the same as the existing handling for CUDA and HSA. We don't really have a good way to test it in multiple configurations. |
jhuber6
force-pushed
the
DLOpenFFI
branch
2 times, most recently
from
a681c1a
to
bebcaec
Compare
openmp/libomptarget/plugins-nextgen/generic-elf-64bit/dynamic_ffi/ffi.h
Outdated
Show resolved
Hide resolved
Summary: The CPU targets currently rely on `libffi` to invoke the "kernel" functions. Previously we would not build these if this dependency was not found. This patch copies th eapproach used for things like CUDA and HSA to dynamically load this if it is not found. The one sketchy thing this does is hard-code the default ABI for the target. These are normally defined on a per-file basis in the FFI source, so I had to fish out the expected values. We only use two types, so ideally we will always be able to use the default ABI. It's possible we could remove this dependency entirely in the future as well.
|
After this patch landed our new flang+openmp bot started complaining https://lab.llvm.org/staging/#/builders/140/builds/71 |
…#77495) Summary: The CPU targets currently rely on `libffi` to invoke the "kernel" functions. Previously we would not build these if this dependency was not found. This patch copies th eapproach used for things like CUDA and HSA to dynamically load this if it is not found. The one sketchy thing this does is hard-code the default ABI for the target. These are normally defined on a per-file basis in the FFI source, so I had to fish out the expected values. We only use two types, so ideally we will always be able to use the default ABI. It's possible we could remove this dependency entirely in the future as well.
Summary:
The CPU targets currently rely on
libffito invoke the "kernel"functions. Previously we would not build these if this dependency was
not found. This patch copies th eapproach used for things like CUDA and
HSA to dynamically load this if it is not found.
The one sketchy thing this does is hard-code the default ABI for the
target. These are normally defined on a per-file basis in the FFI
source, so I had to fish out the expected values. We only use two types,
so ideally we will always be able to use the default ABI.
It's possible we could remove this dependency entirely in the future as
well.