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

Thu Apr 28 09:55:10 PDT 2016

Alexandre,

Thanks for your thoughts on this. I was thinking that each subproject
library would be responsible for handling its own name and any associated
branding. For example, when evangelizing for StreamExecutor, I plan to
refer to it as StreamExecutor, not parallel_libs-StreamExecutor or
something like that. So I think it is OK for the top-level container
project to have an undistinguished name. Does that sound reasonable?

On Thu, Apr 28, 2016 at 7:09 AM Alexandre Eichenberger <alexe at us.ibm.com>
wrote:

> A suggestion on naming: by choosing too generic a name, you don't get any
> branding.
>
> My point for the omp library: if someone talks about GOMP, KMPC / IOMP, or
> LOMP, they would know we are talking about the GNU, Intel, IBM
> implementation. I don't think we get that with OMP, which was selected for
> the OMP runtime.
>
> So I would suggest to append "llvm" or "lr" for LLVM runtime, or something
> distinctive that you like.
>
> This make sense because users will have choices of runtimes, gcc linking
> to GOMP, LLVM runtime, LOMP on POWER; GOMP, LLVM, IOMP on Intel... and we
> will need to educate our users on which one to use.
>
> Alexandre
>
>
> -----------------------------------------------------------------------------------------------------
> Alexandre Eichenberger, Master Inventor, Advanced Compiler Technologies
> - research: compiler optimization (OpenMP, multithreading, SIMD)
> - info: alexe at us.ibm.com http://www.research.ibm.com/people/a/alexe
> - phone: 914-945-1812 (work) 914-312-3618 (cell)
>
>
>
> ----- Original message -----
> From: Andrey Bokhanko via cfe-dev <cfe-dev at lists.llvm.org>
> Sent by: "cfe-dev" <cfe-dev-bounces at lists.llvm.org>
> To: Jason Henline <jhen at google.com>
>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, clang developer list <
> cfe-dev at lists.llvm.org>, "openmp-dev at lists.llvm.org" <
> openmp-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] [Openmp-dev] [llvm-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support libraries
> Date: Thu, Apr 28, 2016 9:23 AM
>
> Jason,
>
> Very nice write-up. Well done!
>
> My two kopecks (before you asked, one kopeck is the smallest item of
> currency in Russia ;-)):
> * Bugzilla and mailing list requirements are not covered. Do you want to
> have a component in Bugzilla for each project? One for all of them? Mailing
> list -- a separate list for each project? (IMHO, an overkill) One for all
> of them?
> * Build system -- I suppose you expect all of the libs to be built
> separately, without a single unified cmake file. Correct? Also, I expect
> you want all of the libs to be integrated into LLVM build -- correct? This
> should be spelled out explicitly.
> * I don't really like "parallel" in the name. Both SE and libomptarget are
> libraries that handle offloading, not parallelism. I understand other
> libraries, to be added in the future, might deal with parallelism, but
> maybe we need a separate project for them? (Something Chris already
> hinted.) How about "offloading_lib"?
>
> Yours,
> Andrey
>
>
> On Wed, Apr 27, 2016 at 7:58 PM, Jason Henline via Openmp-dev <
> openmp-dev at lists.llvm.org> wrote:
>
> I've put together a proposed "charter" for this new project, which I am
> calling parallel_utils (although I'm very open to suggestions for a better
> name). The text of my charter is below, and I welcome any input on how it
> can be improved.
>
>
> =====================================================
> LLVM Parallel Utils Subproject Charter
> =====================================================
>
> ----------------------------------------------
> Description
> ----------------------------------------------
> 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.
>
> Libraries in the `parallel_utils` 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_utils` 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_utils` 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.
>
>
> LLVM license
> ------------
> For simplicity, the `parallel_utils` 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.
>
> On Wed, Apr 27, 2016 at 9:52 AM Jason Henline <jhen at google.com> wrote:
>
> Andrey,
>
> I may have misunderstood Chandler, but I think it would be good to house
> libomptarget together with SE in the new project. I suspect he means to
> leave the option open for the libomptarget developers to choose the best
> option as they see fit.
>
> In terms of organization, I would expect the project initially to contain
> a StreamExecutor directory and a libomptarget directory where each project
> could work separately.
>
> When it comes to the difference in review process between the two
> projects, I don't know the answer. I would expect the new project to handle
> reviews similar to the way they are handled in the LLVM project itself, so
> I don't know if there would be any difference compared to what is happening
> now with libomptarget.
>
> On Wed, Apr 27, 2016 at 9:32 AM C Bergström <openmp-dev at lists.llvm.org>
> wrote:
>
> I respect Hal's more tactful approach and response..
>
> Let me play devils advocate for a minute
>
> 1) Yet another programming model - Is the advantage spelled out
> somewhere? (I know there are reasons, but I'd like to see a FAQ or
> this clearly documented. Examples pretty please.. More for long term
> than my own selfish benefit)
> 2) Is this an "open standard" - If I wanted to propose a major change
> to SE - how would I or someone else go about it? OpenMP/ACC have more
> or less clearly defined paths for new features.. What's the governing
> policy here.. Bug fixes are easy to deal with, but does Google have
> final say on the roadmap..
> 3) When the project is created - will it include lots of good tests?
> 4) It's probably used internally @google - who else will be using
> this? Is the target HPC, Android.. etc
>
> Lastly - sorry, but I don't like this kick-the-can approach to what
> should be proper engineering and planning upfront. Can someone @google
> gentleman's promise to actively work on playing nice with other
> projects, specifically OpenMP and Intel. From my perspective nothing
> stops Google from tossing it up on github or google code and letting
> it stay there until all the pieces are in the correct place. Why it
> *must* be an llvm project now doesn't make sense to me. When the shoe
> was on the other foot (OpenMP) there was all sorts of shit and redtape
> Intel (and others) had to jump around to get it included. Google has a
> lot of good karma in the llvm community and maybe that's the
> difference..
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
>
> _______________________________________________
>
>
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160428/e48ec2e3/attachment.html>