[llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
Jason Henline via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 27 13:45:02 PDT 2016
Maybe a “lib” suffix, like “parallel_lib”
parallel_lib sounds good to me. Let's make that the proposed name rather
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>
> 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,
> 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev