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

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

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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160422/c305c65e/attachment.html>

Jason can probably take on the non-trivial task of writing this up more
formally and make sure it is clearly documented.

I'm glad to do this, and I'm planning to start work on it next week.

On Fri, Apr 22, 2016 at 3:24 PM Chandler Carruth <chandlerc at gmail.com>
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?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160422/e9cb0a90/attachment.html>

> On Apr 22, 2016, at 3:24 PM, Chandler Carruth <chandlerc at
gmail.com> wrote:
> 
> On Fri, Apr 22, 2016 at 3:05 PM Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
> 
> > On Apr 22, 2016, at 3:01 PM, Chandler Carruth <chandlerc at
gmail.com <mailto: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?
Yes.
I just think we need to be careful about having clear layering/decoupling
between the various pieces of the libraries I think (I'm not sure if
low-level/high-level is the right distinction for instance, it would require
some thoughts), but the LLVM community is usually pretty good a this (even if
the recent "discussions" around lld indicated it is not always a
given).

-- 
Mehdi


> (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?
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160422/1cb50611/attachment.html>

Chandler,

Thank you for getting it up to ML top.

I believe we have to move broader than that you just mentioned. The natural
separation of the infrastructure into different parts can be across the
following lines:

- the parallel model of programming - these can be OpenMP, OpenACC,
CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc.
- the offloading machinery to be used by any of those above and providing
unified interfaces across all targets to be supported
- the performance libraries collection that can be re-used in different
programming models and be targeting different host/targets planforms

I would like to touch the 2nd bullet, since I had most exerience with
it.There should be a single interface for all offloading players that are
willing to take part. Those are not limited to StreamExecutor and the
OpenMP already published in LLVM. There are number of solutions from Intel,
not saying of others, - it would be reasonable to become a platform for all
of them, and I got positive feedback on the idea within.
To name a few (don't take it as an ad):

 - Hetero Streams Library, https://01.org/hetero-streams-library
 - Beignet Project, https://01.org/beignet
 - Math Kernel Libraries, https://software.intel.com/en-us/intel-mkl
 - Intel Compiler, https://software.intel.com/en-us/intel-compilers

I believe we shouldn't make any difference between StreamExecutor and other
projects and to try to plug one into the other or vice versa. The better
would be to reuse the same ground level I/O machinery that will provide
efficiency to all of these and the newcomers. The machinery should have
some specific attributes, such as support of multitude of languages
currently employed by LLVM project and beyond. Also we have to take into
account different application of the compiler and infrastructure: there can
be server solutions where we are free to use full-featured C++ and there
can be embedded solutions, such as automotive, where customers are tend to
have as few runtime support as possible and like C the most.



Regards,
Sergos
Intel Compilers




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/20160425/0f5922f5/attachment.html>

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>

On Apr 27, 2016, at 9:58 AM, Jason Henline via Openmp-dev <openmp-dev at
lists.llvm.org> wrote:
> The LLVM open source project will contain a subproject named
`parallel_utils` which will host the development of libraries which are aimed at
enabling parallelism in code and which are also closely tied to compiler
technology.  Examples of libraries suitable for hosting within the
`parallel_utils` subproject are runtime libraries and parallel math libraries.
The initial candidates for inclusion in this subproject are StreamExecutor and
libomptarget which would live in the `streamexecutor` and `libomptarget`
subdirectories of `parallel_utils`, respectively.
> 
> The `parallel_utils` project will host a collection of libraries where each
library may be dependent on other libraries from the project or may be
completely independent of any other libraries in the project. The rationale for
hosting independent libraries within the same subproject is that all libraries
in the project are providing related functionality that lives at the
intersection of parallelism and compiler technology. It is expected that some
libraries which initially began as independent will develop dependencies over
time either between existing libraries or by extracting common code that can be
used by each. One of the purposes of this subproject is to provide a working
space where such refactoring and code sharing can take place.
Perhaps this is the intent, but I’d suggest specifically scoping the project to
being “runtime” libraries specifically: things like math libraries are great to
have, but something like a suite of auto-parallelization passes should be in
another subproject.  This avoids some license issues we currently have, but also
helps more directly express the intent of the project and make the scope more
clear.  This would also allow you to replace the “utils” suffix with “rt”, to
mirror compiler_rt.

-Chris

On Wed, Apr 27, 2016 at 3:49 PM Chris Lattner via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Apr 27, 2016, at 9:58 AM, Jason Henline via Openmp-dev <
> openmp-dev at lists.llvm.org> wrote:
> > The LLVM open source project will contain a subproject named
> `parallel_utils` which will host the development of libraries which are
> aimed at enabling parallelism in code and which are also closely tied to
> compiler technology.  Examples of libraries suitable for hosting within the
> `parallel_utils` subproject are runtime libraries and parallel math
> libraries. The initial candidates for inclusion in this subproject are
> StreamExecutor and libomptarget which would live in the `streamexecutor`
> and `libomptarget` subdirectories of `parallel_utils`, respectively.
> >
> > The `parallel_utils` project will host a collection of libraries where
> each library may be dependent on other libraries from the project or may be
> completely independent of any other libraries in the project. The rationale
> for hosting independent libraries within the same subproject is that all
> libraries in the project are providing related functionality that lives at
> the intersection of parallelism and compiler technology. It is expected
> that some libraries which initially began as independent will develop
> dependencies over time either between existing libraries or by extracting
> common code that can be used by each. One of the purposes of this
> subproject is to provide a working space where such refactoring and code
> sharing can take place.
>
> Perhaps this is the intent, but I’d suggest specifically scoping the
> project to being “runtime” libraries specifically: things like math
> libraries are great to have, but something like a suite of
> auto-parallelization passes should be in another subproject.

Thing is, math libraries are often classified as not being "runtime"
libraries. There is essentially a stricter definition of "runtime
library"
that means a library which is *only* called by the compiler, not by users,
ever.

Anyways, I'm fine with using the term "runtime" and suffix
"rt" provided we
make it clear that it's OK if the library API is actually a user-facing API
and it just has some other compiler involvement (like being implemented
using LLVM-specific extensions).


>   This avoids some license issues we currently have,

Do note that the proposal is not to try to avoid these and to allow linking
the Support library into these runtime libraries. Currently, for several of
the candidates, they really need substantial basic infrastructure that
should be shared with other LLVM projects. So we'll eventually need a
proper solution for using those from runtime libs. =/ We're just OK living
with these libs falling under the LLVM license for now.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/aa7dc42f/attachment.html>

On Apr 27, 2016, at 12:57 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> Perhaps this is the intent, but I’d suggest specifically scoping the
project to being “runtime” libraries specifically: things like math libraries
are great to have, but something like a suite of auto-parallelization passes
should be in another subproject.
> 
> Thing is, math libraries are often classified as not being
"runtime" libraries. There is essentially a stricter definition of
"runtime library" that means a library which is *only* called by the
compiler, not by users, ever.
> 
> Anyways, I'm fine with using the term "runtime" and suffix
"rt" provided we make it clear that it's OK if the library API is
actually a user-facing API and it just has some other compiler involvement (like
being implemented using LLVM-specific extensions).
Oh ok, I see the distinction you’re making here.  Maybe a “lib” suffix, like
“parallel_lib”?  The concern I have is that “utils” is just completely vacuous.
>  
>   This avoids some license issues we currently have,
> 
> Do note that the proposal is not to try to avoid these and to allow linking
the Support library into these runtime libraries. Currently, for several of the
candidates, they really need substantial basic infrastructure that should be
shared with other LLVM projects. So we'll eventually need a proper solution
for using those from runtime libs. =/ We're just OK living with these libs
falling under the LLVM license for now.
Ok!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/032b3e3b/attachment.html>

Maybe a “lib” suffix, like “parallel_lib”

parallel_lib sounds good to me. Let's make that the proposed name rather
than parallel_util.

On Wed, Apr 27, 2016 at 1:32 PM Chris Lattner <clattner at apple.com>
wrote:
> On Apr 27, 2016, at 12:57 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
> Perhaps this is the intent, but I’d suggest specifically scoping the
> project to being “runtime” libraries specifically: things like math
> libraries are great to have, but something like a suite of
> auto-parallelization passes should be in another subproject.
>
> Thing is, math libraries are often classified as not being
"runtime"
> libraries. There is essentially a stricter definition of "runtime
library"
> that means a library which is *only* called by the compiler, not by users,
> ever.
>
> Anyways, I'm fine with using the term "runtime" and suffix
"rt" provided
> we make it clear that it's OK if the library API is actually a
user-facing
> API and it just has some other compiler involvement (like being implemented
> using LLVM-specific extensions).
>
>
> Oh ok, I see the distinction you’re making here.  Maybe a “lib” suffix,
> like “parallel_lib”?  The concern I have is that “utils” is just completely
> vacuous.
>
>
>
>>   This avoids some license issues we currently have,
>
>
> Do note that the proposal is not to try to avoid these and to allow
> linking the Support library into these runtime libraries. Currently, for
> several of the candidates, they really need substantial basic
> infrastructure that should be shared with other LLVM projects. So we'll
> eventually need a proper solution for using those from runtime libs. =/
> We're just OK living with these libs falling under the LLVM license for
now.
>
>
> Ok!
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/01c45818/attachment.html>