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

[Mehdi Amini via llvm-dev]

> On Apr 22, 2016, at 3:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> I feel like this thread got a bit stalled. I'd like to pick it up and try to suggest a path forward.
> 
> I don't hear any real objections to the overall idea of having an LLVM subproject for parallelism runtimes and support libraries. I think we should get that created.

I think it should be clarified if "parallelism runtimes and support libraries" are intended to expose user-level APIs or if these are intended to expose APIs for the compiler generated code (this may be part of your point about "writing up its charter, scope" but I also think it shouldn't be underestimated as a task so I called it out).

Otherwise you plan sounds good to me.

-- 
Mehdi



> 
> I don't actually see any real objections to StreamExecutor being one of the runtimes. There are some interesting questions however:
> - Is there common code in the OpenMP runtime that could be unified with this?
> - Could OpenMP end up using SE or some common shared library between them as a basis for offloading?
> - Would instead it make more sense to have the OpenMP offload library be a plugin for StreamExecutor?
> 
> I don't know the answer to any of these really, but I also don't think that they should prevent us from making progress here. And I think if anything, they'll become easier to answer if we do.
> 
> So my suggestion would be:
> 1) Create the broader scoped LLVM subproject, including writing up its charter, scope, plans, etc.
> 
> 2) Add stream executor to it
> 
> 3) Initially, leave the OpenMP offloading stuff targeted at OpenMP. Then, as it evolves, consider moving it to be another runtime in the broad project if and when it makes sense.
> 
> 4) As both OpenMP and SE evolve and are used some in the project, evaluate whether there is a common core that makes sense to extract. If so, do it and rebase them appropriately.
> 
> 
> Does this make sense? Are there objections to moving forward here?