llvm dev - Jun 2016 - [Openmp-dev] parallel-lib: New LLVM Suproject

Thanks for your help, Tanya!

I haven't created the project in SVN yet. Am I able to set it up myself on
the LLVM servers, or does someone else need to do that part?

I'll be glad to volunteer to moderate the new mailing lists.

We will want a website. I think there will be a top-level docs directory
for the project and a docs directory for each subproject. To begin with,
StreamExecutor will be the only subproject so the structure will look
something like this:

parallel-libs/
  docs/
  stream_executor/
    docs/

Does that seem like a reasonable way to set it up?

On Wed, Jun 15, 2016 at 8:44 PM Tanya Lattner <tanyalattner at llvm.org>
wrote:
> Jason,
>
> This sounds good. Have you created the project in SVN yet?
>
> I’ll need to do the post commit hook to the mailing lists, plus set up
> mailing lists. Would anyone want to volunteer to moderate the new mailing
> lists? Will you have docs that need updating or website?
>
> -Tanya
>
> On Jun 13, 2016, at 11:01 AM, Jason Henline <jhen at google.com>
wrote:
>
> Hi Tanya,
>
> As discussed in the past few weeks in the llvm-dev thread “RFC: Proposing
> an LLVM subproject for parallelism runtime and support libraries”, we would
> like to start a new LLVM subproject called parallel-libs (a kind of a
> parallel cousin to compiler-rt), and I was told you were the one to contact
> in order to get it created. The charter for the project is included below.
> Are you able to get this subproject set up?
>
> Thanks for your help,
> -Jason
>
>
> Charter:
> ====================================================> LLVM parallel-libs
Subproject Charter
> ====================================================>
> ----------------------------------------------
> Description
> ----------------------------------------------
> The LLVM open source project will contain a subproject named
> `parallel-libs` 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-libs` 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-libs`, respectively.
>
> The `parallel-libs` 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.
>
> Libraries in the `parallel-libs` subproject may also depend on the LLVM
> core libraries. This will be useful for avoiding duplication of code within
> the LLVM project for common utilities such as those found in the LLVM
> support library.
>
>
> ----------------------------------------------
> Requirements
> ----------------------------------------------
> Libraries included in the `parallel-libs` subproject must strive to
> achieve the following requirements:
>
> 1. Adhere to the LLVM coding standards.
> 2. Use the LLVM build and test infrastructure.
> 3. Be released under LLVM's license.
>
>
> Coding standards
> ----------------
> Libraries in `parallel-libs` will match the LLVM coding standards. For
> existing projects being checked into the subproject as-is, an exception
> will be made during the initial check-in, with the understanding that the
> code will be promptly updated to follow the standards. Therefore, a three
> month grace period will be allowed for new libraries to meet the LLVM
> coding standards.
>
> Additional exceptions to strict adherence to the LLVM coding standards may
> be allowed in certain other cases, but the reasons for such exceptions must
> be discussed and documented on a case-by-case basis.
>
>
> LLVM build and test infrastructure
> ----------------------------------
> Using the LLVM build and test infrastructure currently means using `cmake`
> for building, `lit` for testing, and `buildbot` for automating build and
> testing. This project will follow the main LLVM project conventions here
> and track them as they evolve.
>
> Each subproject library will be able to build separately without a single,
> unified cmake file, but each subproject libraries will also be integrated
> into the LLVM build so they can be built directly from the top level of the
> LLVM cmake infrastructure.
>
>
> LLVM license
> ------------
> For simplicity, the `parallel-libs` project will use the normal LLVM
> license. While some runtime libraries use a dual license scheme in LLVM, we
> anticipate the project removing the need for this eventually and in the
> interim follow the simpler but still permissive license. Among other
> things, this makes it straightforward for these libraries to re-use core
> LLVM libraries where appropriate.
>
>
> ----------------------------------------------
> Mailing List and Bugs
> ----------------------------------------------
> Two mailing lists will be set up for the project:
>
> 1. parallel_libs-dev at lists.llvm.org for discussions among project
> developers, and
> 2. parallel_libs-commits at lists.llvm.org for patches and commits to the
> project.
>
> Each subproject library will manage its own components in Bugzilla. So,
> for example, there can be several Bugzilla components for different parts
> of StreamExecutor, etc.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/31d88979/attachment-0001.html>

On Fri, Jun 17, 2016 at 1:50 AM, Jason Henline via Openmp-dev
<openmp-dev at lists.llvm.org> wrote:
> Thanks for your help, Tanya!
>
> I haven't created the project in SVN yet. Am I able to set it up myself
on
> the LLVM servers, or does someone else need to do that part?
>
> I'll be glad to volunteer to moderate the new mailing lists.
>
> We will want a website. I think there will be a top-level docs directory
for
> the project and a docs directory for each subproject. To begin with,
> StreamExecutor will be the only subproject so the structure will look
> something like this:
>
> parallel-libs/
>   docs/
>   stream_executor/
>     docs/
>
> Does that seem like a reasonable way to set it up?
What will it look like when they add the liboffload from OMP?

Would it be parallel-libs/libomptarget/
or
parallel-libs/omp/libomptarget/

If there's any code in SE which is "common" and can or should be
reused to consumed - maybe give some long term consideration to
superficial refactoring. This "lib/API" design mentality is common in
llvm/clang and it would be nice if it was mirrored here.

Would it be parallel-libs/libomptarget/
or
parallel-libs/omp/libomptarget/

To me the second way seems better because it seems likely that other OpenMP
stuff could end up in there in the long run.

Once we decide on which code to share, I think we will end up with new
directories at the top level for those common components.

On Thu, Jun 16, 2016 at 10:59 AM C Bergström <cbergstrom at pathscale.com>
wrote:
> On Fri, Jun 17, 2016 at 1:50 AM, Jason Henline via Openmp-dev
> <openmp-dev at lists.llvm.org> wrote:
> > Thanks for your help, Tanya!
> >
> > I haven't created the project in SVN yet. Am I able to set it up
myself
> on
> > the LLVM servers, or does someone else need to do that part?
> >
> > I'll be glad to volunteer to moderate the new mailing lists.
> >
> > We will want a website. I think there will be a top-level docs
directory
> for
> > the project and a docs directory for each subproject. To begin with,
> > StreamExecutor will be the only subproject so the structure will look
> > something like this:
> >
> > parallel-libs/
> >   docs/
> >   stream_executor/
> >     docs/
> >
> > Does that seem like a reasonable way to set it up?
>
> What will it look like when they add the liboffload from OMP?
>
> Would it be parallel-libs/libomptarget/
> or
> parallel-libs/omp/libomptarget/
>
> If there's any code in SE which is "common" and can or should
be
> reused to consumed - maybe give some long term consideration to
> superficial refactoring. This "lib/API" design mentality is
common in
> llvm/clang and it would be nice if it was mirrored here.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/8d2e0c84/attachment.html>

> On Jun 16, 2016, at 10:50 AM, Jason Henline <jhen at google.com>
wrote:
> 
> Thanks for your help, Tanya!
> 
> I haven't created the project in SVN yet. Am I able to set it up myself
on the LLVM servers, or does someone else need to do that part?
You can do this yourself within the llvm-project SVN repository.
> 
> I'll be glad to volunteer to moderate the new mailing lists.
Thanks!
> 
> We will want a website. I think there will be a top-level docs directory
for the project and a docs directory for each subproject. To begin with,
StreamExecutor will be the only subproject so the structure will look something
like this:
> 
> parallel-libs/
>   docs/
>   stream_executor/
>     docs/
> 
> Does that seem like a reasonable way to set it up?
> 
Yes for docs. Virtually all the projects have a www directory within their
project. That usually holds static web pages. Then there is a docs directory
that has either static docs or sphinx generated docs. Doxygen would also fall in
there. The scripts are all set up to handle this sort of project layout (www and
docs).

You could probably easily have a top level www for parallel-libs and also each
project have its own website if needed or not. Its fine for each subprojects to
have its own docs dir.. they would just get built separately unless you set up
cmake to build everything at the top level and combine the docs? Not sure how
you want that to work.

-Tanya



> On Wed, Jun 15, 2016 at 8:44 PM Tanya Lattner <tanyalattner at llvm.org
<mailto:tanyalattner at llvm.org>> wrote:
> Jason,
> 
> This sounds good. Have you created the project in SVN yet?
> 
> I’ll need to do the post commit hook to the mailing lists, plus set up
mailing lists. Would anyone want to volunteer to moderate the new mailing lists?
Will you have docs that need updating or website?
> 
> -Tanya
> 
>> On Jun 13, 2016, at 11:01 AM, Jason Henline <jhen at google.com
<mailto:jhen at google.com>> wrote:
>> 
>> Hi Tanya,
>> 
>> As discussed in the past few weeks in the llvm-dev thread “RFC:
Proposing an LLVM subproject for parallelism runtime and support libraries”, we
would like to start a new LLVM subproject called parallel-libs (a kind of a
parallel cousin to compiler-rt), and I was told you were the one to contact in
order to get it created. The charter for the project is included below. Are you
able to get this subproject set up?
>> 
>> Thanks for your help,
>> -Jason
>> 
>> 
>> Charter:
>> ====================================================>> LLVM
parallel-libs Subproject Charter
>> ====================================================>> 
>> ----------------------------------------------
>> Description
>> ----------------------------------------------
>> The LLVM open source project will contain a subproject named
`parallel-libs` 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-libs` 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-libs`, respectively.
>> 
>> The `parallel-libs` 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.
>> 
>> Libraries in the `parallel-libs` subproject may also depend on the LLVM
core libraries. This will be useful for avoiding duplication of code within the
LLVM project for common utilities such as those found in the LLVM support
library.
>> 
>> 
>> ----------------------------------------------
>> Requirements
>> ----------------------------------------------
>> Libraries included in the `parallel-libs` subproject must strive to
achieve the following requirements:
>> 
>> 1. Adhere to the LLVM coding standards.
>> 2. Use the LLVM build and test infrastructure.
>> 3. Be released under LLVM's license.
>> 
>> 
>> Coding standards
>> ----------------
>> Libraries in `parallel-libs` will match the LLVM coding standards. For
existing projects being checked into the subproject as-is, an exception will be
made during the initial check-in, with the understanding that the code will be
promptly updated to follow the standards. Therefore, a three month grace period
will be allowed for new libraries to meet the LLVM coding standards.
>> 
>> Additional exceptions to strict adherence to the LLVM coding standards
may be allowed in certain other cases, but the reasons for such exceptions must
be discussed and documented on a case-by-case basis.
>> 
>> 
>> LLVM build and test infrastructure
>> ----------------------------------
>> Using the LLVM build and test infrastructure currently means using
`cmake` for building, `lit` for testing, and `buildbot` for automating build and
testing. This project will follow the main LLVM project conventions here and
track them as they evolve.
>> 
>> Each subproject library will be able to build separately without a
single, unified cmake file, but each subproject libraries will also be
integrated into the LLVM build so they can be built directly from the top level
of the LLVM cmake infrastructure.
>> 
>> 
>> LLVM license
>> ------------
>> For simplicity, the `parallel-libs` project will use the normal LLVM
license. While some runtime libraries use a dual license scheme in LLVM, we
anticipate the project removing the need for this eventually and in the interim
follow the simpler but still permissive license. Among other things, this makes
it straightforward for these libraries to re-use core LLVM libraries where
appropriate.
>> 
>> 
>> ----------------------------------------------
>> Mailing List and Bugs
>> ----------------------------------------------
>> Two mailing lists will be set up for the project:
>> 
>> 1. parallel_libs-dev at lists.llvm.org <mailto:parallel_libs-dev at
lists.llvm.org> for discussions among project developers, and
>> 2. parallel_libs-commits at lists.llvm.org
<mailto:parallel_libs-commits at lists.llvm.org> for patches and commits
to the project.
>> 
>> Each subproject library will manage its own components in Bugzilla. So,
for example, there can be several Bugzilla components for different parts of
StreamExecutor, etc.
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/10a0ef0e/attachment.html>