<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:17 PM, Michael Kruse wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CADPO-WAzZQCrgSh6yxa3Tma+uzzmB34gQYaST0syxZ+Au8jJOA@mail.gmail.com">
      
      <div dir="auto">
        <div>Correct. 
          <div dir="auto"><br>
          </div>
          <div dir="auto">I inferred from your response that we have no
            such guarantee yet, we just haven't broken it yet.</div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">However, I think that change will break ABI of
            libomptarget-nvptx.a</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>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.</p>
    <p> -Hal<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CADPO-WAzZQCrgSh6yxa3Tma+uzzmB34gQYaST0syxZ+Au8jJOA@mail.gmail.com">
      <div dir="auto">
        <div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">Just want to clarify what ABI stability
            guarantees we have.</div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">Michael</div>
          <br>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">Le jeu. 9 juil. 2020 à
              17:08, Hal Finkel <<a href="mailto:hfinkel@anl.gov" moz-do-not-send="true">hfinkel@anl.gov</a>> a écrit :<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
              On 7/9/20 3:39 PM, Michael Kruse wrote:<br>
              > Am Do., 9. Juli 2020 um 14:08 Uhr schrieb Hal Finkel
              <<a href="mailto:hfinkel@anl.gov" target="_blank" rel="noreferrer" moz-do-not-send="true">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, 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 plugins,<br>
              >> and the plugins and the device-side runtimes.
              There is an ABI boundary<br>
              >> there somewhere. If we change nothing else, we
              might need to consider<br>
              >> ABI stability of this part of the device-side
              interface.<br>
              > The official distribution <a href="http://apt.llvm.org" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">apt.llvm.org</a>
              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 href="https://releases.llvm.org/download.html" rel="noreferrer noreferrer" target="_blank" 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 with<br>
              > CUDA). The official ubuntu repository doesn't contain
              libomptarget at<br>
              > all. Arch Linux contains at least the x86_64 rtl<br>
              > (<a href="https://www.archlinux.org/packages/extra/x86_64/openmp/files/" rel="noreferrer noreferrer" target="_blank" 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 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 change in <br>
              libomptarget. Changing the device-side runtime doesn't
              necessarily imply <br>
              that. Nevertheless, certainly good to know.<br>
              <br>
                -Hal<br>
              <br>
              <br>
              ><br>
              > Michael<br>
              <br>
              -- <br>
              Hal Finkel<br>
              Lead, Compiler Technology and Programming Languages<br>
              Leadership Computing Facility<br>
              Argonne National Laboratory<br>
              <br>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>