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

[Hal Finkel via llvm-dev]

----- 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>