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

[Michael Kruse via Openmp-dev]

Ye was referring to libomp/libomptarget specifically mixed with
different versions of clang. Could you clarify what "+1" to?

Michael

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
>