[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:21 PM, Michael Kruse wrote:
> Ye was referring to libomp/libomptarget specifically mixed with
> different versions of clang. Could you clarify what "+1" to?
>
> Michael


Certainly. Good point. I was referring to the device-side runtime 
library (as in the title of the RFC), and I interpreted Ye's comments in 
that context. We do consider ABI stability for libomp. For libomptarget, 
on the host, it's not obvious to me that's really ready for ABI 
stability either, but as you point out, we might want to consider it as 
distributions are installing it in system-wide locations. That, however, 
should be a separate discussion (or, at least, a separately-titled 
discussion).

  -Hal


>
> Am Do., 9. Juli 2020 um 13:11 Uhr schrieb Hal Finkel <hfinkel at anl.gov>:
>>
>> 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
>>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory