[llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

[Chandler Carruth via llvm-dev]

On Wed, Apr 27, 2016 at 3:49 PM Chris Lattner via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Apr 27, 2016, at 9:58 AM, Jason Henline via Openmp-dev <
> openmp-dev at lists.llvm.org> wrote:
> > 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.
> >
> > 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.
>
> 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.


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.

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).



>   This avoids some license issues we currently have,


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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/aa7dc42f/attachment.html>