<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:33 PM, Johannes Doerfert
wrote:<br>
</div>
<blockquote type="cite" cite="mid:9f5a2d18-2aad-f58c-eaca-931b23b2d5f8@gmail.com">
<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>
</blockquote>
<p><br>
</p>
<p>I think that we should separate these concerns.</p>
<p>The device-side runtime library is a static library (in IR form),
and multiple different versions can co-exist within one
application (in device code contained in different shared
libraries). It seems completely reasonable to consider that
version-locked to the compiler that compiled the code. It's an
internal interface between two parts of a translation unit
compiled by the same compiler.</p>
<p>libomptarget is a shared library. libomptarget.rtl.cuda.so is a
shared library. Unless we take special care in the naming and
linking, managing of global state, etc. I think that we need to
consider these to have some kind of ABI stability (because you
only get to have one in each process). That doesn't mean that we
can't ever decide to break that ABI, but we would likely decide
not to do so silently. This implies that the device-side runtime
should maintain ABI compatibility with libomptarget.rtl.cuda.so
unless we make a non-silent breaking change. Just having kernels
in a shared library suddenly stop working correctly when a newer
version of libomptarget.rtl.cuda.so is loaded is probably not
something we can considerately do at this point.</p>
<p> -Hal</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:9f5a2d18-2aad-f58c-eaca-931b23b2d5f8@gmail.com">
<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" moz-do-not-send="true">hfinkel@anl.gov</a>
<a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov" moz-do-not-send="true"><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" moz-do-not-send="true">hfinkel@anl.gov</a>
<a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov" moz-do-not-send="true"><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" moz-do-not-send="true"><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" moz-do-not-send="true">https://releases.llvm.org/download.html</a>
<br>
<a class="moz-txt-link-rfc2396E" href="https://releases.llvm.org/download.html" moz-do-not-send="true"><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/" moz-do-not-send="true">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/" moz-do-not-send="true"><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" moz-do-not-send="true">Openmp-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>