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

Hal Finkel via llvm-dev
Wed, 01 Jun 2016 11:22:17 -0000

----- Original Message -----

> From: "C Bergström" <cbergstrom at pathscale.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev"
> <cfe-dev at lists.llvm.org>, "openmp-dev" <openmp-dev at
lists.llvm.org>,
> "Chandler Carruth" <chandlerc at gmail.com>, "Carlo
Bertolli"
> <cbertol at us.ibm.com>, "Andrey Bokhanko"
<andreybokhanko at gmail.com>
> Sent: Wednesday, June 1, 2016 12:19:19 AM
> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support libraries

> The thread has lost focus and cherry picking replies..

> To restate things since maybe you missed my points
> ----
> 1) SE is a programming model and needs a home of it's own. Having a
> programming model with it's headers and all other stuff glued into a
> runtime project which intends to be universal and PM agnostic
> doesn't make sense.

They'd start in separate subdirectories.

> 1.1) The more I look, the most it seems SE is just a step-child
> project and stuffing it in llvm while still not having any users or
> strong backing doesn't make sense. We have enough PM already and my
> gut feeling is this isn't going in a direction to bring in other
> stakeholders.

I think this is the core of my reply. OpenMP has a strong user community, but
OpenMP 4 offloading is still young. OpenMP 4 offloading does not yet have a real
user community yet because the first implementations just started shipping very
recently. Furthermore, our implementation is certainly quite new, and OpenMP 4
offloading is really quite akin to SE in that regard. I view them both as
experimental projects, and both have strong backing with significant investment,
so I expect both to mature over time. Our non-subtle strategic goal as a
community should be to encourage the various teams to take advantage of each
others expertise in the most practical way.

> 2) Parallel name sucks -1, too generic. imho project is more focused
> on offloading. We're not proposing the whole OpenMP runtime be
> merged here, but just the offloading part. Yes onloading will be
> included, but just the generic pieces.

I agree that the 'openmp' runtime project logically fits within the
purview of a 'parallel' project. We may even want to move it there
eventually. We might also want it to remain separate while the project uses its
own coding conventions (which are different from LLVM's coding conventions
for historical reasons). We're not yet had that conversation, but it is a
good one to have.

Thanks again,
Hal

--

Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/b36e93a4/attachment.html>