[Openmp-dev] [RFC] Clarify the absence of API stability for the *device runtime* (aka. libomptarget-nvptx-sm_XX.bc)

[Hal Finkel via Openmp-dev]

On 7/9/20 3:39 PM, Michael Kruse wrote:
> Am Do., 9. Juli 2020 um 14:08 Uhr schrieb Hal Finkel <hfinkel at anl.gov>:
>> Also, if we wanted to change clang so that it linked version-locked
>> versions of these libraries, -lomptarget-11 or whatever, that, in my
>> opinion, would also be a reasonable choice to discuss.
>>
>> One thing worth capturing is the extent to which these things are
>> connected. There is a relationship between libomptarget and its plugins,
>> and the plugins and the device-side runtimes. There is an ABI boundary
>> there somewhere. If we change nothing else, we might need to consider
>> ABI stability of this part of the device-side interface.
> The official distribution apt.llvm.org contains libomptarget.so for
> LLVM 7 to 10, but each into separate directories under
> /usr/lib/llvm-<version>/libomptarget.so. The prebuilt binaries under
> https://releases.llvm.org/download.html puts it directly under
> <prefix>/libomptarget.so. If libomptarget is version-locked, users
> need to be careful about pointing to the right LD_LIBRARY_PATH.
> However, I could not find target device plugins in the distributions
> (such as lib/libomptarget-nvptx-sm_60.bc when built on a machine with
> CUDA). The official ubuntu repository doesn't contain libomptarget at
> all. Arch Linux contains at least the x86_64 rtl
> (https://www.archlinux.org/packages/extra/x86_64/openmp/files/)
> without any versioning resolution.
>
> Should make it explicit what the compatibility guarantees for
> libomptarget are, maybe even discourage OS distributions to
> pre-package libomptarget into ldconfig default paths? At least on Arch
> Linux updating the openmp package will break previously
> compiled-with-offloading binaries.


You mean that it will break them *if* we make an ABI-breaking change in 
libomptarget. Changing the device-side runtime doesn't necessarily imply 
that. Nevertheless, certainly good to know.

  -Hal


>
> Michael

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory