[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 1:05 PM, Michael Kruse wrote:
> 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


We're not discussing these. You're talking about host-side runtime 
libraries. This is for the device-side runtime library only (e.g.,  
libomptarget-nvptx-sm_XX.bc).

  -Hal


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

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