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

Tue Apr 26 08:06:52 PDT 2016

Chandler,

It seems that the general consensus is to save further discussions for
later and go ahead with your proposal. I can add my +1 to this as well.

Could you / Jason prepare a proposal on the new project, with all the usual
questions covered? One interesting thing is where to put SE and
libomptarget in the project's tree. I would be happy to review it from
Intel / OpenMP side.

Also, as Carlo noted, libomptarget is currently under review (a bit stalled
one, if I may say so). Do we expect SE to undergo through a similar review
-- piece by piece -- as well?

Yours,
Andrey
======
Software Engineer
Intel Compiler Team

On Sat, Apr 23, 2016 at 1:24 AM, Chandler Carruth via Openmp-dev <
openmp-dev at lists.llvm.org> wrote:

> On Fri, Apr 22, 2016 at 3:05 PM Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>>
>> > 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).
>>
>
> Absolutely. I think that needs to be clearly spelled out.
>
> Personally, I'd like to see the subproject open to *both*. Here are some
> libraries I would love to see (but don't necessarily have concrete plans
> around):
> - A nice vectorized math library
> - Linear algebra libraries like BLAS implementations or such
> - Highly tuned FFT or other domain specific libraries for GPUs.
> Essentially the same is the vectorized math libraries but for GPUs and
> slightly higher level.
> - Stream executor
> - Any generic components of the OpenMP libraries.
>
> Clearly each of these would need to be discussed on a case by case basis,
> but there seems to be a healthy mixture of both user-level APIs and
> compiler-level APIs. I would suggest criteria for being here along the
> lines of:
>
> - Includes compiler-targeted APIs (maybe in addition to user-level APIs,
> maybe even with overlap), or
> - Leverages compiler details for its implementation (for example, using
> vector extensions we know LLVM supports), or
> - Wants to use compiler-specific packaging techniques or other integration
> techniques (for example shipping as bitcode), or
> - Helps support compiler or programming language functionality
>
> The first three here seem clear cut to me. If any part of the library is
> intended to be callable by the compiler, its a good fit. SE has such
> interfaces. Vectorized math libraries do too, etc. If the implementation of
> th elibrary really wants to use compiler internals like our vector math
> extensions, again, I think it makes sense to keep it reasonably co-located
> with the compiler.
>
> The last seems a bit tricky, but I think its really important. Currently,
> CUDA provides a pretty big programming surface, and having a well tuned
> BLAS or FFT implementation for example that integrates with CUDA is pretty
> important. Similarly in the future, we expect C++ to get lots of parallel
> standard library interfaces, potentially even BLAS-looking ones and we
> might want a good parallel BLAS implementation or other very fundamental
> parallel library implementation to use when implementing it.
>
> But at the same time, I think its really important to have a clear place
> where any library here ties back into the compiler ecosystem and/or the
> programming language ecosystem that are the core of LLVM.
>
> Does this seem like its going in the right direction? (Jason can probably
> take on the non-trivial task of writing this up more formally and make sure
> it is clearly documented.)
>
>
>> 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?
>>
>>
> _______________________________________________
> 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/llvm-dev/attachments/20160426/292781a9/attachment.html>