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

Mon May 9 10:45:29 PDT 2016

On Mon, May 9, 2016 at 11:33 AM Jason Henline via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I talked to Chandler about the name "offload_libs" vs "parallel_libs" and
> he said he thinks "offload" is too narrow of a term for the scope he sees
> for this subproject. One example he brought up was AVX 512. He thinks that
> code explicitly targeting CPU parallelism should also be included in this
> project, even though it doesn't fit in the category of "offloading". So
> that is an argument in favor of "parallel_libs" instead of "offload_libs".
>
> Chandler, please correct me if I misrepresented your thoughts on this.
>

No, you summed it up. And sorry I didn't promptly send those thoughts here,
but thanks for relaying our in-person conversation.

>
> On Thu, Apr 28, 2016 at 9:55 AM Jason Henline <jhen at google.com> wrote:
>
>> 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
>>>
>>> _______________________________________________
> 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/20160509/90bd3ff0/attachment.html>