<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 8:21 AM Mehdi Amini via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jun 1, 2016, at 7:42 AM, C Bergström via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On Wed, Jun 1, 2016 at 8:52 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
>> ----- Original Message -----<br>
>>> From: "C Bergström" <<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>><br>
>>> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
>>> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, "cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>, "openmp-dev"<br>
>>> <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>>, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>, "Carlo Bertolli" <<a href="mailto:cbertol@us.ibm.com" target="_blank">cbertol@us.ibm.com</a>>,<br>
>>> "Andrey Bokhanko" <<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>><br>
>>> Sent: Wednesday, June 1, 2016 6:46:57 AM<br>
>>> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support<br>
>>> libraries<br>
>>><br>
>>> On Wed, Jun 1, 2016 at 7:22 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
>>>><br>
>>>> ________________________________<br>
>>>><br>
>>>> From: "C Bergström" <<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>><br>
>>>> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
>>>> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, "cfe-dev"<br>
>>>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>, "openmp-dev" <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>>,<br>
>>>> "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>, "Carlo Bertolli"<br>
>>>> <<a href="mailto:cbertol@us.ibm.com" target="_blank">cbertol@us.ibm.com</a>>, "Andrey Bokhanko" <<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>><br>
>>>> Sent: Wednesday, June 1, 2016 12:19:19 AM<br>
>>>> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an<br>
>>>> LLVM<br>
>>>> subproject for parallelism runtime and support libraries<br>
>>>><br>
>>>> The thread has lost focus and cherry picking replies..<br>
>>>><br>
>>>> To restate things since maybe you missed my points<br>
>>>> ----<br>
>>>> 1) SE is a programming model and needs a home of it's own. Having a<br>
>>>> programming model with it's headers and all other stuff glued into<br>
>>>> a runtime<br>
>>>> project which intends to be universal and PM agnostic doesn't make<br>
>>>> sense.<br>
>>>><br>
>>>> They'd start in separate subdirectories.<br>
>>>><br>
>>>><br>
>>>> 1.1) The more I look, the most it seems SE is just a step-child<br>
>>>> project and<br>
>>>> stuffing it in llvm while still not having any users or strong<br>
>>>> backing<br>
>>>> doesn't make sense. We have enough PM already and my gut feeling is<br>
>>>> this<br>
>>>> isn't going in a direction to bring in other stakeholders.<br>
>>><br>
>>> Point by point because I don't agree with what you write below<br>
>>> entirely<br>
>>><br>
>>>><br>
>>>> I think this is the core of my reply. OpenMP has a strong user<br>
>>>> community,<br>
>>><br>
>>> I'd agree here<br>
>>><br>
>>>> but OpenMP 4 offloading is still young.<br>
>>><br>
>>> ditto<br>
>>><br>
>>>> OpenMP 4 offloading does not yet<br>
>>>> have a real user community<br>
>>><br>
>>> agreement<br>
>>><br>
>>>> yet because the first implementations just<br>
>>>> started shipping very recently.<br>
>>><br>
>>> Partially strongly disagree - Maybe you meant on Power8?<br>
>>> Intel has had their support for OMP4 for quite some time. It may have<br>
>>> been buggy and focused on simd directive, but as best I can tell they<br>
>>> have worked quite hard to fix bugs and improve it.<br>
>><br>
>> I meant across many platforms. Intel had preliminary support for OpenMP 4 offloading directives even before OpenMP 4 was standardized (in 2013). This did not include all of what ended up in the standard, and the offloading part of the standard needed to be fixed in a breaking way for OpenMP 4.1/4.5 regardless, so this is certainly the exception rather than the rule.<br>
>><br>
>>><br>
>>> (Shameless self promotion) We have had some degree of OMP4 offloading<br>
>>> for like 1.5 years now.. It's mostly targeting the GPU and x86, but<br>
>>> also more recently working on Power8/AArch64.<br>
>>><br>
>>> I'm quite certain these companies all have varying degrees of OMP4<br>
>>> done: Cray, IBM, PGI<br>
>><br>
>> Yes, many are working on implementations, and some have shipped. There's a list here: <a href="http://openmp.org/wp/openmp-compilers/" rel="noreferrer" target="_blank">http://openmp.org/wp/openmp-compilers/</a> - no one here really lists any OpenMP 4 offloading implementations before 2015. PGI does not currently list OpenMP 4 at all (although they've certainly done a lot of work on OpenACC).<br>
>><br>
>>><br>
>>>> Furthermore, our implementation is certainly<br>
>>>> quite new, and OpenMP 4 offloading is really quite akin to SE in<br>
>>>> that<br>
>>>> regard.<br>
>>><br>
>>> Strongly disagree - Intel has been working with the LLVM community on<br>
>>> the parsing/sema and other parts of OMP4 for like a year or more..<br>
>>> This has been a long and well vetted process backed back a well<br>
>>> defined standard.<br>
>><br>
>> Yes, both Intel and IBM have contributed significantly to Clang in this regard.<br>
>><br>
>>> Compared to SE which is just some thing that popped<br>
>>> up out of nowhere and<br>
>><br>
>> It popped up in TensorFlow, which itself popped up out of nowhere, but is already a popular open-source project for machine learning.<br>
>><br>
>>> has a couple people from Google throwing their<br>
>>> weight around.<br>
>><br>
>> Google is a trusted member of the LLVM community and a major contributor. So I agree with you in the following sense: When Google promises to update the code to follow LLVM's coding conventions and to manage its future development in accordance with our community norms, I believe them. I think they've earned a place in the "trust but verify" category in this regard, and I think this is a positive thing.<br>
>><br>
><br>
> yes, but not every project that is started is finished and who would<br>
> be the maintainer if the person leaves Google?<br>
<br>
Like anything that bitrot and is no longer maintained in LLVM: it gets deleted (or the sources stay there but it is no longer updated/maintained).<br>
There are precedents: <a href="http://llvm.org/svn/llvm-project/" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/</a></blockquote><div><br></div><div>Strong +1.</div><div><br></div><div>This is no different than any of other significant contributions, by Google or other significant contributor -- we're on the hook to maintain it. If we stop doing that, it gets nuked.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<br>
> I still don't see why<br>
> they can't fork it on github or create a project to let it bake and<br>
> get some users or traction.<br>
<br>
The intent may be that instead of creating a separate community of users, it'd create its community inside the llvm projects community. That looks like a nice "feature" long term.<br>
<br>
Cost/benefit: cost is not really existent, potential benefits are interesting.<br></blockquote><div><br></div><div>Agreed. That is exactly why we were interested in contributing it to LLVM. We think it makes both LLVM and SE stronger from a community perspective to have the diversity here.</div></div></div>