<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2/11/20 7:50 AM, Jim Cownie via
      Openmp-dev wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:E78C5161-6DB7-4005-A0CA-D5D00B71B45D@gmail.com">
      
      <pre style="white-space: pre-wrap; font-variant-ligatures: normal; orphans: 2; widows: 2;" class=""><blockquote type="cite" class="">On 2/11/20 4:56 AM, Jon Chesterfield via Openmp-dev wrote:
><i class="">
</i>><i class="">     Hmm, so you propose creating a dependency from the OpenMP runtime to
</i>><i class="">     the LLVM libraries? Which classes would you want to use, probably some
</i>><i class="">     of the ADTs? Does any of the other runtime libraries (libc++,
</i>><i class="">     libc++abi, compiler-rt, sanitizers) already do this? IIRC
</i>><i class="">     libc++abi and
</i>><i class="">     LLVMSupport share some demangling code, but that is manually copied.
</i>><i class="">
</i>><i class="">
</i>><i class=""> I am unaware that each subproject reimplements code to avoid a 
</i>><i class=""> dependency on llvm. My first reaction is "surely not", but it's not 
</i>><i class=""> totally implausible. I will look into this.
</i>><i class="">
</i>><i class=""> ADT is the obvious contender for reuse. There will also be a lot of OS 
</i>><i class=""> wrappers somewhere. File IO, dlopen, probably memory allocators. 
</i>><i class=""> Essentially all the stuff a big cross platform C++ project grows over 
</i>><i class=""> time. In the case of anything hitting the filesystem, also 
</i>><i class=""> treacherously difficult to get right across platforms.
</i>><i class="">
</i>><i class=""> There's an open patch against libomptarget that uses dlopen with a 
</i>><i class=""> hardcoded path length. Opt loads shared libraries on windows afaik so 
</i>><i class=""> probably has a robust wrapper around dlopen, so I'd start there.
</i>

I would separate these two discussions. One motivation for the 
relicensing effort is to allow sharing code between runtime libraries 
and the core infrastructure. I expect that, as we move to full coverage 
on various parts of the relicensing, we'll have a large-scale discussion 
about how to implement this resuse across the project. However, we can 
certainly use C++14 language features before we worry about using LLVM's 
support library.

  -Hal
</blockquote></pre>
      <div class="">I agree wth Hal; there are two different issues here
        which have potentailly different implications :-</div>
      <div class="">
        <ol class="MailOutline">
          <li class="">Choice of base language level (C++11 or C++14)</li>
          <li class="">Moving code backwards and forwards between the
            runtime and the compiler, or adding additional runtime
            library requirements on users of the OpenMP runtime.</li>
        </ol>
        <div class=""><br class="">
        </div>
      </div>
      <div class="">Changing the language dialect seems a small an
        uncontentious thing to do.</div>
      <div class="">However adding additional dependencies seems more
        problematic. It is important that the runtime should remain
        usable with code compiled by GCC, for instance, even in the
        absence of other libraries. So not just that we support GCC’s
        OpenMP interfaces when we’re dealing with, say, an OpenMP
        program compiled by LLVM which links to a GCC compiled library
        that uses OpenMP, but also an all GCC case, where nothing but
        libomp has been compiled by LLVM. </div>
      <div class=""><br class="">
      </div>
      <div class="">This matters because libomp can provide useful
        performance improvements over libgomp at high core counts, and
        that is useful to some people.</div>
      <div class="">It’s also a nice sales-pitch for LLVM in general :-
        “Look, you were able to use some of LLVM without even
        recompiling your GCC compiled code, and it improved the
        performance. Just think how good it could be if you moved to
        LLVM completely…” :-)</div>
    </blockquote>
    <p><br>
    </p>
    <p>Indeed :-)</p>
    <p>In practice, when we discuss using the LLVM support library in
      the runtime libraries, I expect that we'll also have some
      discussion on how it should be split, or not, how it should be
      linked (statically, dynamically, whatever), what dependencies it
      may have. I expect that we would want this to be pretty
      transparent when we do it.</p>
    <p> -Hal<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:E78C5161-6DB7-4005-A0CA-D5D00B71B45D@gmail.com">
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div style="color: rgb(0, 0, 0); letter-spacing: normal;
          text-align: start; text-indent: 0px; text-transform: none;
          white-space: normal; word-spacing: 0px;
          -webkit-text-stroke-width: 0px; word-wrap: break-word;
          -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
          <div class="">-- Jim<br class="">
            James Cownie <<a href="mailto:jcownie@gmail.com" class="" moz-do-not-send="true">jcownie@gmail.com</a>><br class="">
            Mob: +44 780 637 7146<br class="">
            <br class="">
            <br class="">
            <br class="">
          </div>
        </div>
      </div>
      <br class="">
      <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>