[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[1]. 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.

[1]: 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/0499f5ec/attachment.html>

More information about the llvm-dev mailing list