<div dir="ltr"><div><div><div><div>Thanks Jason (and Chandler) to tell Chandler's opinion, though it still doesn't answer my original question:<br><br>> 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.)<br><br></div>The example simply adds confusion<br><br>> 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".<br><br></div>Do we want to add a vectorizer to this project as well?<br><br></div>Yours,<br></div>Andrey<br><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 8:32 PM, Jason Henline <span dir="ltr"><<a href="mailto:jhen@google.com" target="_blank">jhen@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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".<div><br></div><div>Chandler, please correct me if I misrepresented your thoughts on this.</div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 28, 2016 at 9:55 AM Jason Henline <<a href="mailto:jhen@google.com" target="_blank">jhen@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Alexandre,<div><br></div><div>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?<br><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div><div class="gmail_quote"><div dir="ltr">On Thu, Apr 28, 2016 at 7:09 AM Alexandre Eichenberger <<a href="mailto:alexe@us.ibm.com" target="_blank">alexe@us.ibm.com</a>> wrote:<br></div></div></div></div><div dir="ltr"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><div dir="ltr">A suggestion on naming: by choosing too generic a name, you don't get any branding.</div>
<div dir="ltr"> </div>
<div dir="ltr">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.</div>
<div dir="ltr"> </div>
<div dir="ltr">So I would suggest to append "llvm" or "lr" for LLVM runtime, or something distinctive that you like. </div>
<div dir="ltr"> </div>
<div dir="ltr">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.</div></div><div dir="ltr" style="font-family:Arial;font-size:10.5pt">
<div dir="ltr" style="font-family:Arial;font-size:10.5pt"><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><div dir="ltr"><br>Alexandre<br><br>-----------------------------------------------------------------------------------------------------<br><span style="color:rgb(0,0,205)">Alexandre Eichenberger, Master Inventor, Advanced Compiler Technologies</span><br><span style="color:rgb(0,0,205)">- research</span>: compiler optimization (OpenMP, multithreading, SIMD)<br><span style="color:rgb(0,0,205)">- info:</span> <a href="mailto:alexe@us.ibm.com" target="_blank">alexe@us.ibm.com</a> <a href="http://www.research.ibm.com/people/a/alexe" target="_blank">http://www.research.ibm.com/people/a/alexe</a><br><span style="color:rgb(0,0,205)">- phone</span>: 914-945-1812 (work) 914-312-3618 (cell)</div></div></div></div></div>
<div dir="ltr"> </div>
<div dir="ltr"> </div>
</div><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><blockquote dir="ltr" style="border-left:2px solid rgb(170,170,170);margin-left:5px;padding-left:5px;direction:ltr;margin-right:0px">----- Original message -----<br>From: Andrey Bokhanko via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>Sent by: "cfe-dev" <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>><br>To: Jason Henline <<a href="mailto:jhen@google.com" target="_blank">jhen@google.com</a>><br></blockquote></div><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><blockquote dir="ltr" style="border-left:2px solid rgb(170,170,170);margin-left:5px;padding-left:5px;direction:ltr;margin-right:0px">Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, clang developer list <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>, "<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>" <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>><br>Subject: Re: [cfe-dev] [Openmp-dev] [llvm-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries<br>Date: Thu, Apr 28, 2016 9:23 AM<br>
<div dir="ltr">Jason,
<div><br>Very nice write-up. Well done!</div>
<div> </div>
<div>My two kopecks (before you asked, one kopeck is the smallest item of currency in Russia ;-)):</div>
<div>* 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?</div>
<div>* 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.</div>
<div>* 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"?</div>
<div> </div>
<div>Yours,</div>
<div>Andrey</div>
<div> </div></div>
<div>
<div>On Wed, Apr 27, 2016 at 7:58 PM, Jason Henline via Openmp-dev <span dir="ltr"><<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>></span> wrote:
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.
<div> </div>
<div> </div>
<div><div>=====================================================</div>
<div>LLVM Parallel Utils Subproject Charter</div>
<div>=====================================================</div>
<div> </div>
<div>----------------------------------------------</div>
<div>Description</div>
<div>----------------------------------------------</div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div> </div>
<div>----------------------------------------------</div>
<div>Requirements</div>
<div>----------------------------------------------</div>
<div>Libraries included in the `parallel_utils` subproject must strive to achieve the following requirements:</div>
<div> </div>
<div>1. Adhere to the LLVM coding standards.</div>
<div>2. Use the LLVM build and test infrastructure.</div>
<div>3. Be released under LLVM's license.</div>
<div> </div>
<div> </div>
<div>Coding standards</div>
<div>----------------</div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div> </div>
<div>LLVM build and test infrastructure</div>
<div>----------------------------------</div>
<div>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.</div>
<div> </div>
<div> </div>
<div>LLVM license</div>
<div>------------</div>
<div>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.</div></div>
<div><div>
<div><div dir="ltr">On Wed, Apr 27, 2016 at 9:52 AM Jason Henline <<a href="mailto:jhen@google.com" target="_blank">jhen@google.com</a>> wrote:</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Andrey,
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div></div>
<div><div dir="ltr">On Wed, Apr 27, 2016 at 9:32 AM C Bergström <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> wrote:</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I respect Hal's more tactful approach and response..<br><br>Let me play devils advocate for a minute<br><br>1) Yet another programming model - Is the advantage spelled out<br>somewhere? (I know there are reasons, but I'd like to see a FAQ or<br>this clearly documented. Examples pretty please.. More for long term<br>than my own selfish benefit)<br>2) Is this an "open standard" - If I wanted to propose a major change<br>to SE - how would I or someone else go about it? OpenMP/ACC have more<br>or less clearly defined paths for new features.. What's the governing<br>policy here.. Bug fixes are easy to deal with, but does Google have<br>final say on the roadmap..<br>3) When the project is created - will it include lots of good tests?<br>4) It's probably used internally @google - who else will be using<br>this? Is the target HPC, Android.. etc<br><br>Lastly - sorry, but I don't like this kick-the-can approach to what<br>should be proper engineering and planning upfront. Can someone @google<br>gentleman's promise to actively work on playing nice with other<br>projects, specifically OpenMP and Intel. From my perspective nothing<br>stops Google from tossing it up on github or google code and letting<br>it stay there until all the pieces are in the correct place. Why it<br>*must* be an llvm project now doesn't make sense to me. When the shoe<br>was on the other foot (OpenMP) there was all sorts of shit and redtape<br>Intel (and others) had to jump around to get it included. Google has a<br>lot of good karma in the llvm community and maybe that's the<br>difference..<br>_______________________________________________<br>Openmp-dev mailing list<br><a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a></blockquote></div></blockquote></div></div></div></div><br>_______________________________________________<br>Openmp-dev mailing list<br><a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br> </blockquote></div></div>
</blockquote></div><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><blockquote dir="ltr" style="border-left:2px solid rgb(170,170,170);margin-left:5px;padding-left:5px;direction:ltr;margin-right:0px"><div><font face="Default Monospace,Courier New,Courier,monospace" size="2">_______________________________________________</font></div></blockquote></div><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><blockquote dir="ltr" style="border-left:2px solid rgb(170,170,170);margin-left:5px;padding-left:5px;direction:ltr;margin-right:0px"><div><font face="Default Monospace,Courier New,Courier,monospace" size="2"><br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></font></div></blockquote></div></blockquote></div></div></div></blockquote></div>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>