[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:58 PM, Hal Finkel via Openmp-dev wrote:
>
> 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.


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.

  -Hal


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