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

[Andrey Bokhanko via Openmp-dev]

Ahh, I just noticed that Chandler's proposal is to put SE only into this
new project, and to keep libomptarget separately, in OpenMP project. I
wonder why so? Why SE (a library serving only one PPM so far) is different
from libomptarget (a library also serving only one PPM so far)?

Are people have opinion on this?

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

On Tue, Apr 26, 2016 at 6:06 PM, Andrey Bokhanko <andreybokhanko at gmail.com>
wrote:

> 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/openmp-dev/attachments/20160427/991c5baa/attachment-0001.html>