[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/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 
> <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 <mailto: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 <https://reviews.llvm.org/D83268>
>
>     [1] https://reviews.llvm.org/D83268#2136060
>     <https://reviews.llvm.org/D83268#2136060>
>
>     [2] https://reviews.llvm.org/D83271 <https://reviews.llvm.org/D83271>
>
>     [3] http://llvm.org/PR46450 <http://llvm.org/PR46450>
>
>     _______________________________________________
>     Openmp-dev mailing list
>     Openmp-dev at lists.llvm.org <mailto:Openmp-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>     <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200707/ec576565/attachment-0001.html>