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

[Michael Kruse via Openmp-dev]

Without backward-compatibility between libomp versions, how do we
ensure that the correct version is being linked? I fear a chaos on
user systems, e.g. after updating the linux distribution to a new
version of /usr/lib/libomp.so?

Although distributions may do library versioning (e.g. on Debian I see
libomp.so as a symlink to libomp.so.5), the clang driver just adds
-lomp or -lomptarget to link to the 'latest' version.

Michael

Am Di., 7. Juli 2020 um 10:59 Uhr schrieb Hal Finkel via Openmp-dev
<openmp-dev at lists.llvm.org>:
>
>
> On 7/7/20 10:49 AM, Ye Luo via Openmp-dev wrote:
>
> Even if the API is stable, there is no guarantee for compatibility.
> I was burnt by mixing old system libomp and newer libomptarget.
> http://lists.llvm.org/pipermail/openmp-dev/2019-March/002439.html
>
> As a user, I don't want to get any headache with compatibility. The best way is not even trying it.
> Unless developers are 100% sure mixing works and mixing is covered by rigorous tests, it is better to forbid users trying to mix and later run into problems.
> Compile time stop is better than run time error.
>
> In short, mixing Clang 10 with libomp/libomptarget 11 or mixing Clang 11 with libomp/libomptarget 10 is not expected by me.
>
> Best,
> Ye
> ===================
> Ye Luo, Ph.D.
> Computational Science Division & Leadership Computing Facility
> Argonne National Laboratory
>
>
> +1
>
> Frankly, we're still at the stage where we're making all of this work for non-trivial production applications; we're not yet at the stage where we should be trying to provide cross-version stability on what is really a compiler-internal interface. We've not had a discussion, AFAIK, where we decided on a stability policy for this interface, it's an IR-level interface, and so our default should be to consider it version-locked to LLVM.
>
>  -Hal
>
>
>
>
> On Tue, Jul 7, 2020 at 9:59 AM Johannes Doerfert via Openmp-dev <openmp-dev at lists.llvm.org> wrote:
>>
>> As part of a patch to remove dead arguments [0] a discussion started which asked for an RFC [1].
>>
>>
>> --
>>
>>
>> I want to clarify that there is no guarantee the *device runtime* (aka. libomptarget-nvptx-sm_XX.bc) has a stable API.
>>
>>
>> Quick summary of the discussion:
>>
>> - The library in question is *not* part of libomp (which has a stable API) or even libomptarget.
>>
>> - We are not aware of any non-clang user of this library.
>>
>> - The only usage model we (properly) support is static linking of the runtime as LLVM-IR. This inherently ties the runtime to the compiler (version):
>>
>>   - Combining a new compiler with an old (LLVM-IR) runtime cannot be expected to work as we might have new entry points.
>>
>>   - Combining an old compiler with a new (LLVM-IR) runtime cannot be expected to work as we cannot guarantee the old toolchain can handle the new IR .
>>
>>
>> Please provide feedback asap, this is a requirement for the GPU state machine patch [2] which fixes an important register usage bug [3].
>>
>>
>> Thanks,
>>
>>   Johannes
>>
>>
>>
>> [0] https://reviews.llvm.org/D83268
>>
>> [1] https://reviews.llvm.org/D83268#2136060
>>
>> [2] https://reviews.llvm.org/D83271
>>
>> [3] http://llvm.org/PR46450
>>
>> _______________________________________________
>> Openmp-dev mailing list
>> Openmp-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev