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

Chandler Carruth via Openmp-dev openmp-dev at lists.llvm.org
Tue May 10 14:05:22 PDT 2016


I think both "accelerator" and "offload" have the same problem for me --
they really seem too narrow.

There are a lot of use cases for runtime libraries that are targeted at the
host CPU. Perhaps your host CPU has a nice SIMD unit or it has lots of
cores. Essentially, I feel like at least some of these runtimes are
fundamentally about exploiting parallelism, which is why I argue for that
naming convention.

A concrete example that none have really addressed: a serious use case I
would like to see the project address is to have an LLVM hosted vectorized
math library that we can teach the compiler to leverage when vectorizing
code (and allow users to call directly).

Another example use case that I don't think would be well addressed with
"offload" naming: producing the core runtime support libraries used to
implement the new C++ parallelism TS in libc++.

Now, we could put these libraries into compiler-rt, but I really feel like
they will have more in common with the things in this repository than
compiler-rt.

I would very much like us to go with a *broad* name that allows many use
cases to work effectively in this project, rather than a narrow and
specific name. The libraries themselves should have specific and clear
names, but I don't really want to encourage a proliferation of top level
projects by their charters being overly narrow.

-Chandler

On Tue, May 10, 2016 at 12:14 PM Carlo Bertolli <cbertol at us.ibm.com> wrote:

> Hi
>
> A comment on the naming, while re-reading this thread: it **may** be that
> "acceleration" is a better adjective for the project you have in mind,
> rather than "offloading" (not applicable to AVX and homogeneous clusters of
> Intel Xeon Phi) or "parallel" (everything is parallel at this point).
>
> I actually think that acceleration is too generic as a term, and
> misleading in some cases, but it may fit your needs here.
>
> Thanks
>
> -- Carlo
>
> [image: Inactive hide details for Andrey Bokhanko via Openmp-dev
> ---05/10/2016 11:32:45 AM---On Mon, May 9, 2016 at 9:07 PM, Chandler C]Andrey
> Bokhanko via Openmp-dev ---05/10/2016 11:32:45 AM---On Mon, May 9, 2016 at
> 9:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
>
> From: Andrey Bokhanko via Openmp-dev <openmp-dev at lists.llvm.org>
>
>
> To: Chandler Carruth <chandlerc at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, cfe-dev <cfe-dev at lists.llvm.org>,
> openmp-dev at lists.llvm.org
>
> Date: 05/10/2016 11:32 AM
>
>
> Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support libraries
> Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org>
> ------------------------------
>
>
>
> On Mon, May 9, 2016 at 9:07 PM, Chandler Carruth <*chandlerc at gmail.com*
> <chandlerc at gmail.com>> wrote:
>
>
>    I would not expect a vectorizer to really fit here, no.
>
>
> I didn't actually suggested to include vectorizer (sorry if wasn't clear)
> -- my whole point that "parallel" is too broad and frankly confusing word.
>
> Yours,
>
> Andrey_______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160510/ca36c53b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160510/ca36c53b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160510/ca36c53b/attachment-0001.gif>


More information about the Openmp-dev mailing list