[llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 1 20:43:31 PDT 2016
Just to address a specific point that Andrey raised here:
On Wed, Jun 1, 2016 at 8:43 AM andreybokhanko via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Also, Chris' arguments on SE's lack of users / standard body make a lot
> of sense to me. I remember that CilkPlus was rejected for the same reasons.
> Why SE (PPM, not the library) is different?
One important difference is that CilkPlus is essentially the same level of
complexity as CUDA+SE, and IMO the cost of supporting CUDA in Clang is huge
and dwarfs the other costs here. But all of this is still an important
CilkPlus was proposed quite a long time ago. At that point, things looked
very different: there had been relatively little active engagement in Clang
(which is what was primarily impacted by CilkPlus) by Intel. As a
consequence, the project was essentially looking at accepting a significant
contribution from a source with a limited history. Contributing significant
new functionality outside of any particular standard requires a really
strong level of trust and engagement with the community. Apple (obviously,
and somewhat trivially) built that, and there have been no problems with
Objective-C support in both Clang and LLVM. At Google, we've specifically
invested a lot of time and effort to build that level of relationship with
Clang and the project as a whole. And I'm happy to see Intel and others
investing in the same direction here; I think that's the only healthy way
to push for large changes like this.
Would CilkPlus contributions from Intel be accepted today? I honestly don't
know. Regardless, this will need to be a separate discussion.
Hope that helps explain my perspective here.
: And don't get me wrong, I think it is worth the cost! =] I just don't
want to misrepresent how large those costs are.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev