<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/7/20 10:49 AM, Ye Luo via
Openmp-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CACiEoHmrqXhZ+39Mff42ug_h22WXLd212DdBbArg7Ce4fnj_vQ@mail.gmail.com">
<div dir="ltr">
<div>Even if the API is stable, there is no guarantee for
compatibility.
<div>I was burnt by mixing old system libomp and newer
libomptarget.<br>
</div>
</div>
<div><a href="http://lists.llvm.org/pipermail/openmp-dev/2019-March/002439.html" moz-do-not-send="true">http://lists.llvm.org/pipermail/openmp-dev/2019-March/002439.html</a></div>
<div><br>
</div>
<div>As a user, I don't want to get any headache with
compatibility. The best way is not even trying it.</div>
<div>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.</div>
<div>Compile time stop is better than run time error.</div>
<div><br>
</div>
<div>In short, mixing Clang 10 with libomp/libomptarget 11 or
mixing Clang 11 with libomp/libomptarget 10 is not expected by
me.<br>
</div>
<div><br>
</div>
<div>Best,<br>
</div>
<div>Ye<br>
</div>
<div>
<div>
<div>
<div>
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">===================<br>
Ye Luo, Ph.D.<br>
Computational Science Division & Leadership
Computing Facility<br>
Argonne National Laboratory</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>+1</p>
<p>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.</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CACiEoHmrqXhZ+39Mff42ug_h22WXLd212DdBbArg7Ce4fnj_vQ@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jul 7, 2020 at 9:59 AM
Johannes Doerfert via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">openmp-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><font face="Hack Nerd Font Mono">As part of a patch to
remove dead arguments [0] a discussion started which
asked for an RFC [1].</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">--</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">I want to clarify that
there is no guarantee the *device runtime* (aka.
libomptarget-nvptx-sm_XX.bc) has a stable API.</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">Quick summary of the
discussion:</font></p>
<p><font face="Hack Nerd Font Mono">- The library in
question is *not* part of libomp (which has a stable
API) or even libomptarget.<br>
</font></p>
<p><font face="Hack Nerd Font Mono">- We are not aware of
any non-clang user of this library.<br>
</font></p>
<p><font face="Hack Nerd Font Mono">- 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):<br>
</font></p>
<p><font face="Hack Nerd Font Mono"> - Combining a new
compiler with an old (LLVM-IR) runtime cannot be
expected to work as we might have new entry points.<font face="Hack Nerd Font Mono"><br>
</font></font></p>
<p><font face="Hack Nerd Font Mono"><font face="Hack Nerd
Font Mono"> - 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 .<br>
</font> </font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">Please provide feedback
asap, this is a requirement for the GPU state machine
patch [2] which fixes an important register usage bug
[3].<br>
</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">Thanks,</font></p>
<p><font face="Hack Nerd Font Mono"> Johannes<br>
</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono"><br>
</font></p>
<p><font face="Hack Nerd Font Mono">[0] <a href="https://reviews.llvm.org/D83268" target="_blank" moz-do-not-send="true">https://reviews.llvm.org/D83268</a><br>
</font></p>
<p><font face="Hack Nerd Font Mono">[1] <a href="https://reviews.llvm.org/D83268#2136060" target="_blank" moz-do-not-send="true">https://reviews.llvm.org/D83268#2136060</a></font></p>
<p>[2] <a href="https://reviews.llvm.org/D83271" target="_blank" moz-do-not-send="true">https://reviews.llvm.org/D83271</a><br>
</p>
<p>[3] <a href="http://llvm.org/PR46450" target="_blank" moz-do-not-send="true">http://llvm.org/PR46450</a><br>
</p>
</div>
_______________________________________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">Openmp-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br>
</blockquote>
</div>
<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>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>