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

[Jason Henline via llvm-dev]

Maybe a “lib” suffix, like “parallel_lib”

parallel_lib sounds good to me. Let's make that the proposed name rather
than parallel_util.

On Wed, Apr 27, 2016 at 1:32 PM Chris Lattner <clattner at apple.com> wrote:

> On Apr 27, 2016, at 12:57 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> 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).
>
>
> Oh ok, I see the distinction you’re making here.  Maybe a “lib” suffix,
> like “parallel_lib”?  The concern I have is that “utils” is just completely
> vacuous.
>
>
>
>>   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.
>
>
> Ok!
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/01c45818/attachment.html>