<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/9/20 5:21 PM, Hal Finkel via
Openmp-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:35413736-654d-3302-d18a-de7aca9db32e@anl.gov">
<br>
On 7/9/20 5:17 PM, Michael Kruse wrote:
<br>
<blockquote type="cite">Correct.
<br>
<br>
I inferred from your response that we have no such guarantee
yet, we just haven't broken it yet.
<br>
<br>
However, I think that change will break ABI of
libomptarget-nvptx.a
<br>
</blockquote>
<br>
<br>
I think that this is an important point. I interpreted this thread
in the context of the API between the runtime and the device-side
application code. Not the ABI between the plugin and the
device-side runtime. I suspect these two are separable, but we
should definitely clarify this.
<br>
<br>
</blockquote>
<p><br>
</p>
<p>Neither should be considered stable at this point. We kept
libomptarget stable while we recently added functions but I would
not assume it will stay that way. As I mentioned before, for the
device runtime there is basically no supported way today in which
we could even guarantee stability.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:35413736-654d-3302-d18a-de7aca9db32e@anl.gov"> -Hal
<br>
<br>
<br>
<blockquote type="cite">
<br>
Just want to clarify what ABI stability guarantees we have.
<br>
<br>
Michael
<br>
<br>
<br>
Le jeu. 9 juil. 2020 à 17:08, Hal Finkel <<a class="moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>
<a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov"><mailto:hfinkel@anl.gov></a>> a écrit :
<br>
<br>
<br>
On 7/9/20 3:39 PM, Michael Kruse wrote:
<br>
> Am Do., 9. Juli 2020 um 14:08 Uhr schrieb Hal Finkel
<br>
<<a class="moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> <a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov"><mailto:hfinkel@anl.gov></a>>:
<br>
>> Also, if we wanted to change clang so that it
linked version-locked
<br>
>> versions of these libraries, -lomptarget-11 or
whatever, that,
<br>
in my
<br>
>> opinion, would also be a reasonable choice to
discuss.
<br>
>>
<br>
>> One thing worth capturing is the extent to which
these things are
<br>
>> connected. There is a relationship between
libomptarget and its
<br>
plugins,
<br>
>> and the plugins and the device-side runtimes. There
is an ABI
<br>
boundary
<br>
>> there somewhere. If we change nothing else, we
might need to
<br>
consider
<br>
>> ABI stability of this part of the device-side
interface.
<br>
> The official distribution apt.llvm.org
<a class="moz-txt-link-rfc2396E" href="http://apt.llvm.org"><http://apt.llvm.org></a>
<br>
contains libomptarget.so for
<br>
> LLVM 7 to 10, but each into separate directories under
<br>
> /usr/lib/llvm-<version>/libomptarget.so. The
prebuilt binaries under
<br>
> <a class="moz-txt-link-freetext" href="https://releases.llvm.org/download.html">https://releases.llvm.org/download.html</a>
<br>
<a class="moz-txt-link-rfc2396E" href="https://releases.llvm.org/download.html"><https://releases.llvm.org/download.html></a> puts it
directly under
<br>
> <prefix>/libomptarget.so. If libomptarget is
version-locked, users
<br>
> need to be careful about pointing to the right
LD_LIBRARY_PATH.
<br>
> However, I could not find target device plugins in the
distributions
<br>
> (such as lib/libomptarget-nvptx-sm_60.bc when built on
a machine
<br>
with
<br>
> CUDA). The official ubuntu repository doesn't contain
<br>
libomptarget at
<br>
> all. Arch Linux contains at least the x86_64 rtl
<br>
>
(<a class="moz-txt-link-freetext" href="https://www.archlinux.org/packages/extra/x86_64/openmp/files/">https://www.archlinux.org/packages/extra/x86_64/openmp/files/</a>
<br>
<a class="moz-txt-link-rfc2396E" href="https://www.archlinux.org/packages/extra/x86_64/openmp/files/"><https://www.archlinux.org/packages/extra/x86_64/openmp/files/></a>)
<br>
> without any versioning resolution.
<br>
>
<br>
> Should make it explicit what the compatibility
guarantees for
<br>
> libomptarget are, maybe even discourage OS
distributions to
<br>
> pre-package libomptarget into ldconfig default paths?
At least
<br>
on Arch
<br>
> Linux updating the openmp package will break previously
<br>
> compiled-with-offloading binaries.
<br>
<br>
<br>
You mean that it will break them *if* we make an
ABI-breaking
<br>
change in
<br>
libomptarget. Changing the device-side runtime doesn't
necessarily
<br>
imply
<br>
that. Nevertheless, certainly good to know.
<br>
<br>
-Hal
<br>
<br>
<br>
>
<br>
> Michael
<br>
<br>
-- Hal Finkel
<br>
Lead, Compiler Technology and Programming Languages
<br>
Leadership Computing Facility
<br>
Argonne National Laboratory
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openmp-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openmp-dev@lists.llvm.org">Openmp-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>