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

[Johannes Doerfert via Openmp-dev]

I'll go ahead with the patches today.

What do you mean by fix the runtime part first?


~ Johannes


On 7/9/20 7:18 AM, Alexey.Bataev wrote:
> If there are no objections, it is good to go. Just fix the runtime part
> at first.
>
> -------------
> Best regards,
> Alexey Bataev
>
> 07.07.2020 10:57 AM, Johannes Doerfert пишет:
>> 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
>>