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

[C Bergström via llvm-dev]

I'd love to see this as 2 projects
1) liboffload_rt (if you really want the rt suffix - strictly speaking
it may be just a wrapper depending the the target.)
2) SE - Programming model and user facing API. (It builds on top of
liboffload, but the layers are cleanly separated and is an
implementation detail)

By doing this you avoid the whole parallel_bucket_of_everything. The
OpenMP offload-thing can live in liboffload and hopefully by having
similar code in the same place it will make it easier for
deduplication and sharing. (There's also an OpenCL runtime floating
around that could be moved there if the maintainer was interested..)

Math libs - This is a whole ball of cheese and yet may be best in yet
another project..

On Thu, Apr 28, 2016 at 4:45 AM, 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>
>> 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
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>