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

[Ye Luo via Openmp-dev]

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


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200707/fbea27b3/attachment.html>