<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 27, 2016 at 3:49 PM Chris Lattner via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Apr 27, 2016, at 9:58 AM, Jason Henline via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> wrote:<br>
> The LLVM open source project will contain a subproject named `parallel_utils` which will host the development of libraries which are aimed at enabling parallelism in code and which are also closely tied to compiler technology.  Examples of libraries suitable for hosting within the `parallel_utils` subproject are runtime libraries and parallel math libraries. The initial candidates for inclusion in this subproject are StreamExecutor and libomptarget which would live in the `streamexecutor` and `libomptarget` subdirectories of `parallel_utils`, respectively.<br>
><br>
> The `parallel_utils` project will host a collection of libraries where each library may be dependent on other libraries from the project or may be completely independent of any other libraries in the project. The rationale for hosting independent libraries within the same subproject is that all libraries in the project are providing related functionality that lives at the intersection of parallelism and compiler technology. It is expected that some libraries which initially began as independent will develop dependencies over time either between existing libraries or by extracting common code that can be used by each. One of the purposes of this subproject is to provide a working space where such refactoring and code sharing can take place.<br>
<br>
Perhaps this is the intent, but I’d suggest specifically scoping the project to being “runtime” libraries specifically: things like math libraries are great to have, but something like a suite of auto-parallelization passes should be in another subproject.</blockquote><div><br></div><div>Thing is, math libraries are often classified as not being "runtime" libraries. There is essentially a stricter definition of "runtime library" that means a library which is *only* called by the compiler, not by users, ever.</div><div><br></div><div>Anyways, I'm fine with using the term "runtime" and suffix "rt" provided we make it clear that it's OK if the library API is actually a user-facing API and it just has some other compiler involvement (like being implemented using LLVM-specific extensions).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  This avoids some license issues we currently have,</blockquote><div><br></div><div>Do note that the proposal is not to try to avoid these and to allow linking the Support library into these runtime libraries. Currently, for several of the candidates, they really need substantial basic infrastructure that should be shared with other LLVM projects. So we'll eventually need a proper solution for using those from runtime libs. =/ We're just OK living with these libs falling under the LLVM license for now.</div><div><br></div><div>-Chandler</div></div></div>