[llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 27 14:11:35 PDT 2016
On Wed, Apr 27, 2016 at 4:45 PM Jason Henline via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> 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>
>> 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.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev