Cilk Plus Extension for Clang

Hello All,

Our team would like to add the Cilk Plus extension to Clang for C/C++ (http://software.intel.com/file/40297). To meet the requirements that Clang sets, we would like to keep our patches small and upstream our patches as early as possible. We would appreciate any guidance that the community could provide during the course of the implementation. Attached is our first patch that enables the Cilk Plus extension option. Looking forward to your review and comments!

Thanks!

Wei Pan

Software Engineer
Dynamic Mobility and Parallelism
Intel

fcilkplus.patch (3.82 KB)

This patch doesn't apply against trunk.

-Eli

From: "Wei Pan" <wei.pan@intel.com>
To: "llvm cfe" <cfe-commits@cs.uiuc.edu>
Cc: cfe-dev@cs.uiuc.edu
Sent: Thursday, November 1, 2012 12:09:01 PM
Subject: [cfe-commits] Cilk Plus Extension for Clang

Hello All,

Our team would like to add the Cilk Plus extension to Clang for C/C++
(http://software.intel.com/file/40297). To meet the requirements
that Clang sets, we would like to keep our patches small and
upstream our patches as early as possible. We would appreciate any
guidance that the community could provide during the course of the
implementation. Attached is our first patch that enables the Cilk
Plus extension option. Looking forward to your review and comments!

Wei,

I'd like to voice my support for this; I think that having Cilk Plus support in Clang will be very useful. I look forward to seeing the interesting patches :wink:

Can you comment on what, if any, optimizations will be important for supporting Cilk Plus; either in the frontend or in the backend (or both).

-Hal

Before we go too far, and certainly before we dive in with patches,
there is an important discussion which needs to take place: should
Clang grow support for Cilk Plus.

Clang has strongly resisted the urge to grow support for arbitrary
vendor extensions to the C/C++ programming languages for several
reasons:
- It aims to be a strictly standards enforcing compiler, something
complicated by extensions
- To minimize maintenance burden, and ensure rapid development of Clang itself
- To avoid fragmentation, or supporting competing but different (or
even opposed) extensions

The current guidelines are that it is healthy for Clang to support an
extension when there is a paper in front of the C++ committee which
proposes making that extension part of standard C++, there is an
active committee member backing that proposed extension, and there are
indications of consensus on the direction if not the particulars of
the extension as it will be standardized. Furthermore, if the
extension is still undergoing significant discussion or is not yet
reasonably clear that it will be a part of the upcoming standard, we
really want an active, trusted member of the Clang community to be
backing the implementation so that we have confidence in it getting
updated to match the progress of the proposal to the committee.

The goal here is to balance the desire to foster implementation
experience with extensions to the language prior to standardization
while minimizing the cost on the project and community and maximizing
the quality bar of the primary Clang code base and released
binaries[1][2].

Unfortunately, supporting Cilk Plus has several significant points
that go directly against this strategy for Clang's development:

1) Cilk Plus is a proprietary language feature specified, controlled,
and implemented by a single vendor (Intel). It does not seem
sufficiently general to be of interest to the entire Clang
community[3] in its current form.

2) My understanding is that Cilk requires a runtime library in
addition to the language feature to work well? We wouldn't want to
accept the compiler extensions without a usable runtime library widely
available within the Open Source world, and preferably as part of the
LLVM project itself (http://compiler-rt.llvm.org/) to maximize our
ability to shape the implementation to Clang and LLVM's needs.

3) There has in fact been a proposal to standardize something like
Cilk Plus in C++, but there is strong disagreement within the
committee about the best form for the features, and my personal sense
is that the details would have to change significantly before
standardization[4].

4) To undertake a significant extension to Clang and LLVM (and to have
proper compiler and runtime support for this feature, it would be
quite significant, even if the superficial syntax is simple) would be
a very large maintenance burden. While I'm excited to see a few
patches from you thus far, I think we would need to see significantly
more work with the existing codebase in order to really be comfortable
with the maintenance story for such an extension.

At this point, I suspect it is best if any Cilk Plus extension live
out-of-tree, in a tree maintained exclusively by Intel, preferably in
the open. Then, for Intel contributors to join and engage the Clang
community, taking on significant maintenance work and other upstream
development tasks. When the standards discussion coalesces on a form
that is gaining consensus, and the maintenance track record is in
place, it should be straight forward to migrate support for the
soon-to-be-standard features, in whatever form they take.

I hate to rain on the parade, but I'm trying to watch out for the
Clang community at large here.

-Chandler

[1]: None of this prevents individuals from building their extensions
on top of Clang outside of the primary repository. Many early-stage
extensions start off on github or the like.

[2]: Note that sufficiently well established members of the Clang
community who are also on the standards committee often have leeway to
implement relatively early versions of proposed extensions in Clang.
This is merely a reflection of the degree to which they are trusted
within the community to see matters through and iterate on the design
in concert with the committee.

[3]: This may seem like a double standard -- there are a few major
Clang features that have relatively narrow applicability. However,
those have been contributed by some of the largest and most deeply
invested members of the community. The importance of this rule varies
directly in proportion to the magnitude and length of on-going
contributions a particular vendor makes to the Clang and LLVM open
source projects.

[4] I am an active member of the committee and have been actively
participating in this particular discussion, so while this is merely
my perception, it is a first-hand perspective.

From: "Chandler Carruth" <chandlerc@google.com>
To: "Wei Pan" <wei.pan@intel.com>
Cc: cfe-dev@cs.uiuc.edu, "llvm cfe" <cfe-commits@cs.uiuc.edu>
Sent: Tuesday, November 6, 2012 2:55:31 AM
Subject: Re: [cfe-commits] Cilk Plus Extension for Clang

> Hello All,
>
> Our team would like to add the Cilk Plus extension to Clang for
> C/C++ (http://software.intel.com/file/40297). To meet the
> requirements that Clang sets, we would like to keep our patches
> small and upstream our patches as early as possible. We would
> appreciate any guidance that the community could provide during
> the course of the implementation. Attached is our first patch that
> enables the Cilk Plus extension option. Looking forward to your
> review and comments!

Before we go too far, and certainly before we dive in with patches,
there is an important discussion which needs to take place: should
Clang grow support for Cilk Plus.

I'd like to respond to what you've said; but I'd like to make clear that am in now way connected to Intel's Cilk development. To some extent, I'm playing devil's advocate here...

Clang has strongly resisted the urge to grow support for arbitrary
vendor extensions to the C/C++ programming languages for several
reasons:
- It aims to be a strictly standards enforcing compiler, something
complicated by extensions
- To minimize maintenance burden, and ensure rapid development of
Clang itself
- To avoid fragmentation, or supporting competing but different (or
even opposed) extensions

The current guidelines are that it is healthy for Clang to support an
extension when there is a paper in front of the C++ committee which
proposes making that extension part of standard C++, there is an
active committee member backing that proposed extension, and there
are
indications of consensus on the direction if not the particulars of
the extension as it will be standardized. Furthermore, if the
extension is still undergoing significant discussion or is not yet
reasonably clear that it will be a part of the upcoming standard, we
really want an active, trusted member of the Clang community to be
backing the implementation so that we have confidence in it getting
updated to match the progress of the proposal to the committee.

As you well know, Clang is more than a C/C++ compiler. It supports several other language variants (Objective C++, for example -- and I think there is even some CUDA support hiding somewhere). In addition, we provide an MSVC-compatible mode (can I call that a language interpretation?), and, of course, several GNU extensions. Given that Intel has also developed Cilk support for gcc, we might be able to consider it a GNU extension as well.

I think that we should adopt a purely quality-based approach for accepting these kinds of extensions:
1. Quality of the implementation
2. Quality of the specification
3. "Quality" of the maintenance-work provided

We obviously already have strict rules on code quality, but I think, just as important, is the quality of the specification the code intends to implement. I do not think that quality necessarily means consensus. Failure to reach consensus within the context of a standards committee can reflect other legitimate factors. Furthermore, good standards, IMHO, are constructed based on real experience and implementations. To be of high quality, the specification must be well designed, with all relevant interactions and semantics well defined, and a good match to the target use cases.

We also need a well-defined priority. With interacting specifications, conflicts often arise (there are certainly a large number of POSIX vs C defect reports, for example). Sometimes we can provide a flag to choose which behavior the user would like, sometimes this is not practical. When not practical, we will need to fall back to the specification of higher priority.

The goal here is to balance the desire to foster implementation
experience with extensions to the language prior to standardization
while minimizing the cost on the project and community and maximizing
the quality bar of the primary Clang code base and released
binaries[1][2].

Unfortunately, supporting Cilk Plus has several significant points
that go directly against this strategy for Clang's development:

1) Cilk Plus is a proprietary language feature specified, controlled,
and implemented by a single vendor (Intel). It does not seem
sufficiently general to be of interest to the entire Clang
community[3] in its current form.

I think that vendor control is not nearly as relevant as vendor support. If Intel is willing to commit the resources to support the feature, then that should be the relevant factor. Realistically, Cilk does have a well-defined user community. Furthermore, support for lightweight parallelism is not an industry trend that we can afford to ignore.

2) My understanding is that Cilk requires a runtime library in
addition to the language feature to work well? We wouldn't want to
accept the compiler extensions without a usable runtime library
widely
available within the Open Source world, and preferably as part of the
LLVM project itself (http://compiler-rt.llvm.org/) to maximize our
ability to shape the implementation to Clang and LLVM's needs.

Intel has released Cilk's runtime under a BSD-style license. I absolutely agree that, were Cilk support integrated into Clang, the runtime library should also be included with the distribution.

3) There has in fact been a proposal to standardize something like
Cilk Plus in C++, but there is strong disagreement within the
committee about the best form for the features, and my personal sense
is that the details would have to change significantly before
standardization[4].

4) To undertake a significant extension to Clang and LLVM (and to
have
proper compiler and runtime support for this feature, it would be
quite significant, even if the superficial syntax is simple) would be
a very large maintenance burden. While I'm excited to see a few
patches from you thus far, I think we would need to see significantly
more work with the existing codebase in order to really be
comfortable
with the maintenance story for such an extension.

I agree that we need to make it much easier to plug in syntax extensions into Clang; there will be more to come. Such an interface, however, will need to be driven by use cases. The best way to get this done is to develop it along with proposed extensions.

Of course, we'll need to give careful thought to how these various enhancements will interact, especially, as in this case, where we have multiple ways to expressing parallelism. I would love to see a unified framework. We need to make sure that we have this conversation with as many of the interested parties as possible, and this will only happen if we permit these parties active engagement.

At this point, I suspect it is best if any Cilk Plus extension live
out-of-tree, in a tree maintained exclusively by Intel, preferably in
the open.

I also agree that support should first develop in an outside tree, and then be gradually merged in. This is the only feasible way for this to happen because review time is limited, and when significant changes are demanded, those take time to implement. I also strongly encourage this development tree to be kept in the open.

Then, for Intel contributors to join and engage the Clang
community, taking on significant maintenance work and other upstream
development tasks.

Respectfully, I strongly disagree with this philosophy. Contributors will be most productive working on those things that most interest them. Maybe there are some on Intel's Cilk team that really wish they had been working on core C++ support instead, and in that case, they'll be happy to work on core frontend issues. Otherwise, I'll assume that these people will be most productive working on parallelization, and we should take maximal advantage of that. As they gain experience from working on their area(s) of interest, they will also be able to contribute to other areas of the frontend (and, in due course, they'll need to as they pursue their goals). Vendors should commit to ongoing support of their work, but we should not otherwise have a 'pay to play' policy.

-Hal

We already have a policy for determining whether to accept language
extensions into Clang:

http://clang.llvm.org/get_involved.html

Unless we have a reason to think the policy needs to be amended or is
inapplicable, we should evaluate this extension under its rules. A
number of Chandler's points seem to directly relate to the policy's
requirements.

From: "Chandler Carruth" <chandlerc@google.com>
Clang has strongly resisted the urge to grow support for arbitrary
vendor extensions to the C/C++ programming languages for several
reasons:
- It aims to be a strictly standards enforcing compiler, something
complicated by extensions
- To minimize maintenance burden, and ensure rapid development of
Clang itself
- To avoid fragmentation, or supporting competing but different (or
even opposed) extensions

The current guidelines are that it is healthy for Clang to support an
extension when there is a paper in front of the C++ committee which
proposes making that extension part of standard C++, there is an
active committee member backing that proposed extension, and there
are
indications of consensus on the direction if not the particulars of
the extension as it will be standardized. Furthermore, if the
extension is still undergoing significant discussion or is not yet
reasonably clear that it will be a part of the upcoming standard, we
really want an active, trusted member of the Clang community to be
backing the implementation so that we have confidence in it getting
updated to match the progress of the proposal to the committee.

As you well know, Clang is more than a C/C++ compiler. It supports several other language variants (Objective C++, for example -- and I think there is even some CUDA support hiding somewhere). In addition, we provide an MSVC-compatible mode (can I call that a language interpretation?), and, of course, several GNU extensions. Given that Intel has also developed Cilk support for gcc, we might be able to consider it a GNU extension as well.

This last comment is a stretch to the point of being ridiculous. GNU "extensions" tend to be smallish features that one would encounter when compiling code written with GCC in mind, or with GCC as the primary compiler. Cilk Plus has also been proposed for GCC, but it has not been released as part of GCC, and it's not clear that it will be released as part of GCC. It feels a bit like an arms dealer playing both sides of a conflict :slight_smile:

I think that we should adopt a purely quality-based approach for accepting these kinds of extensions:
1. Quality of the implementation
2. Quality of the specification
3. "Quality" of the maintenance-work provided

We obviously already have strict rules on code quality, but I think, just as important, is the quality of the specification the code intends to implement. I do not think that quality necessarily means consensus. Failure to reach consensus within the context of a standards committee can reflect other legitimate factors. Furthermore, good standards, IMHO, are constructed based on real experience and implementations. To be of high quality, the specification must be well designed, with all relevant interactions and semantics well defined, and a good match to the target use cases.

We also need a well-defined priority. With interacting specifications, conflicts often arise (there are certainly a large number of POSIX vs C defect reports, for example). Sometimes we can provide a flag to choose which behavior the user would like, sometimes this is not practical. When not practical, we will need to fall back to the specification of higher priority.

As Richard pointed out, we have:

  http://clang.llvm.org/get_involved.html#criteria

already. If you want to discuss criteria, discuss those criteria. If you want to argue that Cilk Plus be included in Clang, argue based on those criteria.

Unfortunately, supporting Cilk Plus has several significant points
that go directly against this strategy for Clang's development:

1) Cilk Plus is a proprietary language feature specified, controlled,
and implemented by a single vendor (Intel). It does not seem
sufficiently general to be of interest to the entire Clang
community[3] in its current form.

I think that vendor control is not nearly as relevant as vendor support. If Intel is willing to commit the resources to support the feature, then that should be the relevant factor. Realistically, Cilk does have a well-defined user community.

Someone is free to present evidence that Cilk meets criteria #1 (Evidence of a significant user community).

Furthermore, support for lightweight parallelism is not an industry trend that we can afford to ignore.

Clang's role is to provide a compiler, not to follow industry trends.

4) To undertake a significant extension to Clang and LLVM (and to
have
proper compiler and runtime support for this feature, it would be
quite significant, even if the superficial syntax is simple) would be
a very large maintenance burden. While I'm excited to see a few
patches from you thus far, I think we would need to see significantly
more work with the existing codebase in order to really be
comfortable
with the maintenance story for such an extension.

I agree that we need to make it much easier to plug in syntax extensions into Clang; there will be more to come. Such an interface, however, will need to be driven by use cases. The best way to get this done is to develop it along with proposed extensions.

Of course, we'll need to give careful thought to how these various enhancements will interact, especially, as in this case, where we have multiple ways to expressing parallelism. I would love to see a unified framework. We need to make sure that we have this conversation with as many of the interested parties as possible, and this will only happen if we permit these parties active engagement.

We're not prohibiting these conversations; we're considering whether one of the many possible solutions should become privileged by its inclusion in mainline Clang.

Then, for Intel contributors to join and engage the Clang
community, taking on significant maintenance work and other upstream
development tasks.

Respectfully, I strongly disagree with this philosophy. Contributors will be most productive working on those things that most interest them. Maybe there are some on Intel's Cilk team that really wish they had been working on core C++ support instead, and in that case, they'll be happy to work on core frontend issues. Otherwise, I'll assume that these people will be most productive working on parallelization, and we should take maximal advantage of that. As they gain experience from working on their area(s) of interest, they will also be able to contribute to other areas of the frontend (and, in due course, they'll need to as they pursue their goals).

You absolutely cannot work on an extension the size of Cilk Plus without (1) learning much of the frontend, (2) encountering bugs and inconsistencies that should be fixed in mainline Clang, and (3) encountering places where Clang needs refactoring so that your own work fits in better. There's more than enough in (2) and (3) for an organization---even one that does not care one bit about anything other than their extension---to contribute to Clang. Moreover, it's better for both the community and the person implementing his/her extension that the changes for (2) and (3) get code-reviewed and moved into mainline Clang early, and companies that don't understand this don't make good citizens in the open-source community.

Vendors should commit to ongoing support of their work, but we should not otherwise have a 'pay to play' policy.

It's not 'pay to play', it's a meritocracy. You have to prove both that you're willing and that you are able to provide ongoing support for your own extensions in Clang. The larger, more experimental, or more niche the extension is, the higher the burden to prove continuing support. Statements of commitment hold no sway for a community that will be tasked with ongoing maintenance if you don't live up to your commitment.

Do remember that every major extension adds an ongoing maintenance burden to the LLVM community as a whole. If that burden is not offset by a better user experience for a significant portion of the user population or an increasingly active developer community, it is not a net win.

  - Doug

From: "Douglas Gregor" <dgregor@apple.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Chandler Carruth" <chandlerc@google.com>, cfe-dev@cs.uiuc.edu, "llvm cfe" <cfe-commits@cs.uiuc.edu>
Sent: Tuesday, November 6, 2012 3:57:25 PM
Subject: Re: [cfe-dev] [cfe-commits] Cilk Plus Extension for Clang

>> From: "Chandler Carruth" <chandlerc@google.com>
>> Clang has strongly resisted the urge to grow support for arbitrary
>> vendor extensions to the C/C++ programming languages for several
>> reasons:
>> - It aims to be a strictly standards enforcing compiler, something
>> complicated by extensions
>> - To minimize maintenance burden, and ensure rapid development of
>> Clang itself
>> - To avoid fragmentation, or supporting competing but different
>> (or
>> even opposed) extensions
>>
>> The current guidelines are that it is healthy for Clang to support
>> an
>> extension when there is a paper in front of the C++ committee
>> which
>> proposes making that extension part of standard C++, there is an
>> active committee member backing that proposed extension, and there
>> are
>> indications of consensus on the direction if not the particulars
>> of
>> the extension as it will be standardized. Furthermore, if the
>> extension is still undergoing significant discussion or is not yet
>> reasonably clear that it will be a part of the upcoming standard,
>> we
>> really want an active, trusted member of the Clang community to be
>> backing the implementation so that we have confidence in it
>> getting
>> updated to match the progress of the proposal to the committee.
>
> As you well know, Clang is more than a C/C++ compiler. It supports
> several other language variants (Objective C++, for example -- and
> I think there is even some CUDA support hiding somewhere). In
> addition, we provide an MSVC-compatible mode (can I call that a
> language interpretation?), and, of course, several GNU extensions.
> Given that Intel has also developed Cilk support for gcc, we might
> be able to consider it a GNU extension as well.

This last comment is a stretch to the point of being ridiculous. GNU
"extensions" tend to be smallish features that one would encounter
when compiling code written with GCC in mind, or with GCC as the
primary compiler. Cilk Plus has also been proposed for GCC, but it
has not been released as part of GCC, and it's not clear that it
will be released as part of GCC. It feels a bit like an arms dealer
playing both sides of a conflict :slight_smile:

Agreed :slight_smile: My last comment was intended to be facetious... My serious point was that we do have vendor-supported extensions in Clang.

> I think that we should adopt a purely quality-based approach for
> accepting these kinds of extensions:
> 1. Quality of the implementation
> 2. Quality of the specification
> 3. "Quality" of the maintenance-work provided
>
> We obviously already have strict rules on code quality, but I
> think, just as important, is the quality of the specification the
> code intends to implement. I do not think that quality necessarily
> means consensus. Failure to reach consensus within the context of
> a standards committee can reflect other legitimate factors.
> Furthermore, good standards, IMHO, are constructed based on real
> experience and implementations. To be of high quality, the
> specification must be well designed, with all relevant
> interactions and semantics well defined, and a good match to the
> target use cases.
>
> We also need a well-defined priority. With interacting
> specifications, conflicts often arise (there are certainly a large
> number of POSIX vs C defect reports, for example). Sometimes we
> can provide a flag to choose which behavior the user would like,
> sometimes this is not practical. When not practical, we will need
> to fall back to the specification of higher priority.

As Richard pointed out, we have:

  http://clang.llvm.org/get_involved.html#criteria

already. If you want to discuss criteria, discuss those criteria. If
you want to argue that Cilk Plus be included in Clang, argue based
on those criteria.

Fair enough. Unfortunately, although Chandler did touch on this, the relevant part of the criterion appears to be this, "Clang should drive the standard, not diverge from it. This criterion does not apply to all extensions, since some extensions fall outside of the realm of the standards bodies." The C/C++ committees have adopted library support for parallelism, and perhaps that is enough. If it is not enough (because of overheads, the inherent lack of semantics-aware optimizations, etc.) then we can consider other avenues. Cilk, or some derivative of it, was proposed to the committee, and rejected (according to Chandler's comments). Is the committee likely to adopt some other syntax-based approach in the near future? Or was this kind of extension decided to be out-of-scope for the time being. If it was decided to be out-of-scope, then it qualifies for the exemption.

>> Unfortunately, supporting Cilk Plus has several significant points
>> that go directly against this strategy for Clang's development:
>>
>> 1) Cilk Plus is a proprietary language feature specified,
>> controlled,
>> and implemented by a single vendor (Intel). It does not seem
>> sufficiently general to be of interest to the entire Clang
>> community[3] in its current form.
>
> I think that vendor control is not nearly as relevant as vendor
> support. If Intel is willing to commit the resources to support
> the feature, then that should be the relevant factor.
> Realistically, Cilk does have a well-defined user community.

Someone is free to present evidence that Cilk meets criteria #1
(Evidence of a significant user community).

> Furthermore, support for lightweight parallelism is not an industry
> trend that we can afford to ignore.

Clang's role is to provide a compiler, not to follow industry trends.

While I believe that I understand the feeling behind this remark, in some sense, I feel that it is inaccurate. We support the things that we do because of industry trends, both in terms of languages and in terms of targets. Parallelism is an important current trend because it is necessary for taking full advantage of many modern computing platforms. I am not arguing that Cilk is a realization that we should choose in Clang, but it can certainly be a candidate.

>> 4) To undertake a significant extension to Clang and LLVM (and to
>> have
>> proper compiler and runtime support for this feature, it would be
>> quite significant, even if the superficial syntax is simple) would
>> be
>> a very large maintenance burden. While I'm excited to see a few
>> patches from you thus far, I think we would need to see
>> significantly
>> more work with the existing codebase in order to really be
>> comfortable
>> with the maintenance story for such an extension.
>
> I agree that we need to make it much easier to plug in syntax
> extensions into Clang; there will be more to come. Such an
> interface, however, will need to be driven by use cases. The best
> way to get this done is to develop it along with proposed
> extensions.
>
> Of course, we'll need to give careful thought to how these various
> enhancements will interact, especially, as in this case, where we
> have multiple ways to expressing parallelism. I would love to see
> a unified framework. We need to make sure that we have this
> conversation with as many of the interested parties as possible,
> and this will only happen if we permit these parties active
> engagement.

We're not prohibiting these conversations; we're considering whether
one of the many possible solutions should become privileged by its
inclusion in mainline Clang.

My point is that the conversation will take place among the various stakeholders. If Intel (or anyone else), does not view themselves as a stakeholder, they will not participate.

>> Then, for Intel contributors to join and engage the Clang
>> community, taking on significant maintenance work and other
>> upstream
>> development tasks.
>
> Respectfully, I strongly disagree with this philosophy.
> Contributors will be most productive working on those things that
> most interest them. Maybe there are some on Intel's Cilk team that
> really wish they had been working on core C++ support instead, and
> in that case, they'll be happy to work on core frontend issues.
> Otherwise, I'll assume that these people will be most productive
> working on parallelization, and we should take maximal advantage
> of that. As they gain experience from working on their area(s) of
> interest, they will also be able to contribute to other areas of
> the frontend (and, in due course, they'll need to as they pursue
> their goals).

You absolutely cannot work on an extension the size of Cilk Plus
without (1) learning much of the frontend, (2) encountering bugs and
inconsistencies that should be fixed in mainline Clang, and (3)
encountering places where Clang needs refactoring so that your own
work fits in better. There's more than enough in (2) and (3) for an
organization---even one that does not care one bit about anything
other than their extension---to contribute to Clang. Moreover, it's
better for both the community and the person implementing his/her
extension that the changes for (2) and (3) get code-reviewed and
moved into mainline Clang early, and companies that don't understand
this don't make good citizens in the open-source community.

I completely agree with this; and this was the point I was trying to make.

> Vendors should commit to ongoing support of their work, but we
> should not otherwise have a 'pay to play' policy.

It's not 'pay to play', it's a meritocracy. You have to prove both
that you're willing and that you are able to provide ongoing support
for your own extensions in Clang. The larger, more experimental, or
more niche the extension is, the higher the burden to prove
continuing support. Statements of commitment hold no sway for a
community that will be tasked with ongoing maintenance if you don't
live up to your commitment.

I was specifically responding to Chandler's statement, "Then, for Intel contributors to join and engage the Clang community, taking on significant maintenance work and other upstream development tasks." This very clearly sounds like saying that they need to help us with other stuff first, and moreover, "significant maintenance work" implies significant cost. That is pay-to-play. You may define meritocracy partially in terms of resource commitment, and that's valid, but still implies a cost to the contributor.

My point is that we should not be looking for "significant maintenance work and other upstream development tasks" from them to prove themselves. Ongoing maintenance of their extension in an open public repository, with good code quality, docs and tests, and a positive interaction with the community should be enough.

Do remember that every major extension adds an ongoing maintenance
burden to the LLVM community as a whole. If that burden is not
offset by a better user experience for a significant portion of the
user population or an increasingly active developer community, it is
not a net win.

Agreed.

To be clear, while I do feel that development of parallelism support in Clang is important, and I encourage Intel to develop Cilk for Clang, I have no particular love for Cilk. I do, however, object to the form of Chandler's rejection, and I think that a further discussion was warranted.

Thanks again,
Hal

From: "Hal Finkel" <hfinkel@anl.gov>
To: "Douglas Gregor" <dgregor@apple.com>
Cc: cfe-dev@cs.uiuc.edu, "llvm cfe" <cfe-commits@cs.uiuc.edu>
Sent: Tuesday, November 6, 2012 9:35:22 PM
Subject: Re: [cfe-commits] [cfe-dev] Cilk Plus Extension for Clang

> From: "Douglas Gregor" <dgregor@apple.com>
> To: "Hal Finkel" <hfinkel@anl.gov>
> Cc: "Chandler Carruth" <chandlerc@google.com>, cfe-dev@cs.uiuc.edu,
> "llvm cfe" <cfe-commits@cs.uiuc.edu>
> Sent: Tuesday, November 6, 2012 3:57:25 PM
> Subject: Re: [cfe-dev] [cfe-commits] Cilk Plus Extension for Clang
>
>
>
> >> From: "Chandler Carruth" <chandlerc@google.com>
> >> Clang has strongly resisted the urge to grow support for
> >> arbitrary
> >> vendor extensions to the C/C++ programming languages for several
> >> reasons:
> >> - It aims to be a strictly standards enforcing compiler,
> >> something
> >> complicated by extensions
> >> - To minimize maintenance burden, and ensure rapid development
> >> of
> >> Clang itself
> >> - To avoid fragmentation, or supporting competing but different
> >> (or
> >> even opposed) extensions
> >>
> >> The current guidelines are that it is healthy for Clang to
> >> support
> >> an
> >> extension when there is a paper in front of the C++ committee
> >> which
> >> proposes making that extension part of standard C++, there is an
> >> active committee member backing that proposed extension, and
> >> there
> >> are
> >> indications of consensus on the direction if not the particulars
> >> of
> >> the extension as it will be standardized. Furthermore, if the
> >> extension is still undergoing significant discussion or is not
> >> yet
> >> reasonably clear that it will be a part of the upcoming
> >> standard,
> >> we
> >> really want an active, trusted member of the Clang community to
> >> be
> >> backing the implementation so that we have confidence in it
> >> getting
> >> updated to match the progress of the proposal to the committee.
> >
> > As you well know, Clang is more than a C/C++ compiler. It
> > supports
> > several other language variants (Objective C++, for example --
> > and
> > I think there is even some CUDA support hiding somewhere). In
> > addition, we provide an MSVC-compatible mode (can I call that a
> > language interpretation?), and, of course, several GNU
> > extensions.
> > Given that Intel has also developed Cilk support for gcc, we
> > might
> > be able to consider it a GNU extension as well.
>
> This last comment is a stretch to the point of being ridiculous.
> GNU
> "extensions" tend to be smallish features that one would encounter
> when compiling code written with GCC in mind, or with GCC as the
> primary compiler. Cilk Plus has also been proposed for GCC, but it
> has not been released as part of GCC, and it's not clear that it
> will be released as part of GCC. It feels a bit like an arms dealer
> playing both sides of a conflict :slight_smile:

Agreed :slight_smile: My last comment was intended to be facetious... My serious
point was that we do have vendor-supported extensions in Clang.

>
> > I think that we should adopt a purely quality-based approach for
> > accepting these kinds of extensions:
> > 1. Quality of the implementation
> > 2. Quality of the specification
> > 3. "Quality" of the maintenance-work provided
> >
> > We obviously already have strict rules on code quality, but I
> > think, just as important, is the quality of the specification the
> > code intends to implement. I do not think that quality
> > necessarily
> > means consensus. Failure to reach consensus within the context of
> > a standards committee can reflect other legitimate factors.
> > Furthermore, good standards, IMHO, are constructed based on real
> > experience and implementations. To be of high quality, the
> > specification must be well designed, with all relevant
> > interactions and semantics well defined, and a good match to the
> > target use cases.
> >
> > We also need a well-defined priority. With interacting
> > specifications, conflicts often arise (there are certainly a
> > large
> > number of POSIX vs C defect reports, for example). Sometimes we
> > can provide a flag to choose which behavior the user would like,
> > sometimes this is not practical. When not practical, we will need
> > to fall back to the specification of higher priority.
>
> As Richard pointed out, we have:
>
> http://clang.llvm.org/get_involved.html#criteria
>
> already. If you want to discuss criteria, discuss those criteria.
> If
> you want to argue that Cilk Plus be included in Clang, argue based
> on those criteria.

Fair enough. Unfortunately, although Chandler did touch on this, the
relevant part of the criterion appears to be this, "Clang should
drive the standard, not diverge from it. This criterion does not
apply to all extensions, since some extensions fall outside of the
realm of the standards bodies." The C/C++ committees have adopted
library support for parallelism, and perhaps that is enough. If it
is not enough (because of overheads, the inherent lack of
semantics-aware optimizations, etc.) then we can consider other
avenues. Cilk, or some derivative of it, was proposed to the
committee, and rejected (according to Chandler's comments). Is the
committee likely to adopt some other syntax-based approach in the
near future? Or was this kind of extension decided to be
out-of-scope for the time being. If it was decided to be
out-of-scope, then it qualifies for the exemption.

>
> >> Unfortunately, supporting Cilk Plus has several significant
> >> points
> >> that go directly against this strategy for Clang's development:
> >>
> >> 1) Cilk Plus is a proprietary language feature specified,
> >> controlled,
> >> and implemented by a single vendor (Intel). It does not seem
> >> sufficiently general to be of interest to the entire Clang
> >> community[3] in its current form.
> >
> > I think that vendor control is not nearly as relevant as vendor
> > support. If Intel is willing to commit the resources to support
> > the feature, then that should be the relevant factor.
> > Realistically, Cilk does have a well-defined user community.
>
> Someone is free to present evidence that Cilk meets criteria #1
> (Evidence of a significant user community).
>
> > Furthermore, support for lightweight parallelism is not an
> > industry
> > trend that we can afford to ignore.
>
> Clang's role is to provide a compiler, not to follow industry
> trends.

While I believe that I understand the feeling behind this remark, in
some sense, I feel that it is inaccurate. We support the things that
we do because of industry trends, both in terms of languages and in
terms of targets. Parallelism is an important current trend because
it is necessary for taking full advantage of many modern computing
platforms. I am not arguing that Cilk is a realization that we
should choose in Clang, but it can certainly be a candidate.

>
> >> 4) To undertake a significant extension to Clang and LLVM (and
> >> to
> >> have
> >> proper compiler and runtime support for this feature, it would
> >> be
> >> quite significant, even if the superficial syntax is simple)
> >> would
> >> be
> >> a very large maintenance burden. While I'm excited to see a few
> >> patches from you thus far, I think we would need to see
> >> significantly
> >> more work with the existing codebase in order to really be
> >> comfortable
> >> with the maintenance story for such an extension.
> >
> > I agree that we need to make it much easier to plug in syntax
> > extensions into Clang; there will be more to come. Such an
> > interface, however, will need to be driven by use cases. The best
> > way to get this done is to develop it along with proposed
> > extensions.
> >
> > Of course, we'll need to give careful thought to how these
> > various
> > enhancements will interact, especially, as in this case, where we
> > have multiple ways to expressing parallelism. I would love to see
> > a unified framework. We need to make sure that we have this
> > conversation with as many of the interested parties as possible,
> > and this will only happen if we permit these parties active
> > engagement.
>
> We're not prohibiting these conversations; we're considering
> whether
> one of the many possible solutions should become privileged by its
> inclusion in mainline Clang.

My point is that the conversation will take place among the various
stakeholders. If Intel (or anyone else), does not view themselves as
a stakeholder, they will not participate.

>
> >> Then, for Intel contributors to join and engage the Clang
> >> community, taking on significant maintenance work and other
> >> upstream
> >> development tasks.
> >
> > Respectfully, I strongly disagree with this philosophy.
> > Contributors will be most productive working on those things that
> > most interest them. Maybe there are some on Intel's Cilk team
> > that
> > really wish they had been working on core C++ support instead,
> > and
> > in that case, they'll be happy to work on core frontend issues.
> > Otherwise, I'll assume that these people will be most productive
> > working on parallelization, and we should take maximal advantage
> > of that. As they gain experience from working on their area(s) of
> > interest, they will also be able to contribute to other areas of
> > the frontend (and, in due course, they'll need to as they pursue
> > their goals).
>
> You absolutely cannot work on an extension the size of Cilk Plus
> without (1) learning much of the frontend, (2) encountering bugs
> and
> inconsistencies that should be fixed in mainline Clang, and (3)
> encountering places where Clang needs refactoring so that your own
> work fits in better. There's more than enough in (2) and (3) for an
> organization---even one that does not care one bit about anything
> other than their extension---to contribute to Clang. Moreover, it's
> better for both the community and the person implementing his/her
> extension that the changes for (2) and (3) get code-reviewed and
> moved into mainline Clang early, and companies that don't
> understand
> this don't make good citizens in the open-source community.

I completely agree with this; and this was the point I was trying to
make.

>
> > Vendors should commit to ongoing support of their work, but we
> > should not otherwise have a 'pay to play' policy.
>
>
> It's not 'pay to play', it's a meritocracy. You have to prove both
> that you're willing and that you are able to provide ongoing
> support
> for your own extensions in Clang. The larger, more experimental, or
> more niche the extension is, the higher the burden to prove
> continuing support. Statements of commitment hold no sway for a
> community that will be tasked with ongoing maintenance if you don't
> live up to your commitment.

I was specifically responding to Chandler's statement, "Then, for
Intel contributors to join and engage the Clang community, taking on
significant maintenance work and other upstream development tasks."
This very clearly sounds like saying that they need to help us with
other stuff first, and moreover, "significant maintenance work"
implies significant cost. That is pay-to-play. You may define
meritocracy partially in terms of resource commitment, and that's
valid, but still implies a cost to the contributor.

My point is that we should not be looking for "significant
maintenance work and other upstream development tasks" from them to
prove themselves. Ongoing maintenance of their extension in an open
public repository, with good code quality, docs and tests, and a
positive interaction with the community should be enough.

I'd like to add that the "significant maintenance work and other upstream development tasks" implied to me work aside from that motivated by the extension they wish to integrate. If this is not what was meant, then I apologize.

-Hal

I disagree, at least in part. I think a company as large as Intel, if it wants to contribute such a large vendor-specific extension, does need to prove that it understands how to work well with the open-source community. It is not a process that comes naturally to organizations of that size. They can engage the community either by making general improvements to Clang, or with targeted refactoring and improvements that enable their extension (which are also general goodness for Clang), but there must be *something*. We simply can't take a massive code dump on a promise.

  - Doug

From: "Douglas Gregor" <dgregor@apple.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Chandler Carruth" <chandlerc@google.com>, cfe-dev@cs.uiuc.edu, "llvm cfe" <cfe-commits@cs.uiuc.edu>
Sent: Tuesday, November 6, 2012 11:14:44 PM
Subject: Re: [cfe-dev] [cfe-commits] Cilk Plus Extension for Clang

>
>> From: "Douglas Gregor" <dgregor@apple.com>
>> To: "Hal Finkel" <hfinkel@anl.gov>
>> Cc: "Chandler Carruth" <chandlerc@google.com>,
>> cfe-dev@cs.uiuc.edu, "llvm cfe" <cfe-commits@cs.uiuc.edu>
>> Sent: Tuesday, November 6, 2012 3:57:25 PM
>> Subject: Re: [cfe-dev] [cfe-commits] Cilk Plus Extension for Clang
>>
>>

>>> Vendors should commit to ongoing support of their work, but we
>>> should not otherwise have a 'pay to play' policy.
>>
>>
>> It's not 'pay to play', it's a meritocracy. You have to prove both
>> that you're willing and that you are able to provide ongoing
>> support
>> for your own extensions in Clang. The larger, more experimental,
>> or
>> more niche the extension is, the higher the burden to prove
>> continuing support. Statements of commitment hold no sway for a
>> community that will be tasked with ongoing maintenance if you
>> don't
>> live up to your commitment.
>
> I was specifically responding to Chandler's statement, "Then, for
> Intel contributors to join and engage the Clang community, taking
> on significant maintenance work and other upstream development
> tasks." This very clearly sounds like saying that they need to
> help us with other stuff first, and moreover, "significant
> maintenance work" implies significant cost. That is pay-to-play.
> You may define meritocracy partially in terms of resource
> commitment, and that's valid, but still implies a cost to the
> contributor.
>
> My point is that we should not be looking for "significant
> maintenance work and other upstream development tasks" from them
> to prove themselves. Ongoing maintenance of their extension in an
> open public repository, with good code quality, docs and tests,
> and a positive interaction with the community should be enough.

I disagree, at least in part. I think a company as large as Intel, if
it wants to contribute such a large vendor-specific extension, does
need to prove that it understands how to work well with the
open-source community. It is not a process that comes naturally to
organizations of that size. They can engage the community either by
making general improvements to Clang, or with targeted refactoring
and improvements that enable their extension (which are also general
goodness for Clang), but there must be *something*. We simply can't
take a massive code dump on a promise.

Fair enough. I agree.

Thanks again,
Hal

Doug took all the words out of my mouth for most of this, but I'd like
to clarify what I mean here in particular.

The Cilk proposal was not rejected. I don't really think there has not
been a formal proposal per se... Folks presented Cilk (and many other
technologies in the industry) to the committee to try to help inform
it as to what solutions were out there, and what they might look as
part of standard C++. They've even presented different aspects or
possibilities surrounding a few of the technologies to try to get more
ideas going.

Currently the committee has been giving feedback on exactly how
different aspects would or wouldn't fit into the standard, etc., and
folks seem to be looking into how the fundamental capabilities of
something like Cilk could be best integrated with the language as a
whole. That's what I was trying to say -- the only thing that seems
clear is that we don't yet have a clear picture of what will end up
being in the standard. =] That said, I'm personally confident that
these forms of parallelism *are* in scope for the standard, and
reasonably optimistic that we'll get something figured out in the
C++17 timeframe.

Thanks all for your feedback. I'll try to address some specific points
below,

followed by a proposal for how we move forward.

Cilk Plus has also been proposed for GCC, but it has not been
released as part of GCC, and it's not clear that it will be released as
part
of GCC. It feels a bit like an arms dealer playing both sides of a
conflict
:slight_smile:

While I can't make any statements on behalf of the GCC community, our GCC
Cilk Plus team is committed to merging the Cilk Plus branch into trunk, and
they do expect this to happen eventually based on conversations with the
community thus far.

As Richard pointed out, we have:

http://clang.llvm.org/get_involved.html#criteria

already. If you want to discuss criteria, discuss those criteria. If you
want to argue that Cilk Plus be included in Clang, argue based on those
criteria.

Going by these criteria:

1. Evidence of a significant user community: See below.
2. A specific need to reside within the Clang tree: we are open to making
   Cilk Plus support a plugin if technically feasible, but you indicated at
   the dev meeting that this is probably not the case.
3. A complete specification: We have published specs at
http://cilkplus.org/,
   including:
     http://software.intel.com/file/40297 (language)
     http://software.intel.com/sites/default/files/CilkPlusABI_1.1.pdf
(ABI)
     
http://software.intel.com/sites/default/files/LowOverheadAnnotations.pdf
       (tool annotations)
4. Representation within the appropriate governing organization: As
mentioned
   previously we are actively discussing Cilk Plus in C++. We know there
will
   be changes, and speaking for myself at least, want to ultimately do the
best
   thing for the C++ community. Nonetheless I expect many of the concepts
in
   Cilk Plus to make it into the standard in some form of another, and
strongly
   believe an implementation of the current spec will make future
implementations
   of parallelism in C++17 much easier.
5. A long term support plan: We are very much committed to this, but I
agree
   we still have more work to do to prove ourselves as capable contributors
   in Clang.
6. A high-quality implementation: We are certainly striving to do our best,
   and always open to feedback.
7. A proper test suite: We have a GCC test suite and an internal test
suite,
   both of which we are already using for internal Clang Cilk Plus
   testing today. We are committed to making this test suite available,
   suitably licensed, with the exception of internal cases based on
   customer code we have no license to distribute.
  

Someone is free to present evidence that Cilk meets criteria #1 (Evidence
of a significant user community).

Evans Data Corp did a North American software development survey recently
(http://www.evansdata.com/reports/viewRelease.php?reportID=1
- unfortunately paywalled). Out of 422 responses, filtered to developers
that
target multiple processors or cores, 57 indicated that they use Cilk Plus
today
(13.5%, compared to for example 10.9% for CUDA). Moreover, 38.6% indicated
they
planned on using Cilk Plus in the next year, and Cilk Plus held the
leading place
there out of all other technologies (including OpenCL, TBB, OpenMP, MPI,
CUDA).

We certainly have many active users of Cilk Plus, and based on that report
I
expect this to be on the rise.

Then, for Intel contributors to join and engage the Clang
community, taking on significant maintenance work and other upstream
development tasks.

Respectfully, I strongly disagree with this philosophy. Contributors
will

be most productive working on those things that most interest them. Maybe
there are some on Intel's Cilk team that really wish they had been working
on core C++ support instead, and in that case, they'll be happy to work on
core frontend issues. Otherwise, I'll assume that these people will be
most
productive working on parallelization, and we should take maximal
advantage
of that. As they gain experience from working on their area(s) of
interest,
they will also be able to contribute to other areas of the frontend (and,
in
due course, they'll need to as they pursue their goals).

You absolutely cannot work on an extension the size of Cilk Plus without
(1) learning much of the frontend, (2) encountering bugs and
inconsistencies
that should be fixed in mainline Clang, and (3) encountering places where
Clang needs refactoring so that your own work fits in better. There's more
than enough in (2) and (3) for an organization---even one that does not
care
one bit about anything other than their extension---to contribute to
Clang.
Moreover, it's better for both the community and the person implementing
his/her extension that the changes for (2) and (3) get code-reviewed and
moved into mainline Clang early, and companies that don't understand this
don't make good citizens in the open-source community.

We are very committed to making general improvements to Clang and LLVM. I
believe our contributions to other parts of LLVM (e.g. LLDB) have begun to
demonstrate that we are committed to Do The Right Thing here, but of course
we've only just begun, especially in Clang.

Vendors should commit to ongoing support of their work, but we should not

otherwise have a 'pay to play' policy.

It's not 'pay to play', it's a meritocracy. You have to prove both that
you're willing and that you are able to provide ongoing support for your
own
extensions in Clang. The larger, more experimental, or more niche the
extension is, the higher the burden to prove continuing support.
Statements
of commitment hold no sway for a community that will be tasked with
ongoing
maintenance if you don't live up to your commitment.

Do remember that every major extension adds an ongoing maintenance burden
to the LLVM community as a whole. If that burden is not offset by a better
user experience for a significant portion of the user population or an
increasingly active developer community, it is not a net win.

As mentioned above, I agree we have more work to do here to prove
ourselves.
This kind of feedback really helps us prioritize general contributions, and
we are happy to do so, even if it means delaying the Cilk Plus specific
bits.

A couple of other points:

We fully expect feedback on the specification to arise from both the GCC
and
the Clang implementation. Cilk Plus is still evolving, and I expect it to
evolve further given our standards committee involvement (but it's early
days
there).

Cilk Plus has many components. The "Cilk" parts in particular
(spawn/sync/for)
have been around and evolving since the 90s, and are very solid at this
point.
For other parts, I expect more evolution yet. Perhaps we should not look at
this as an issue of contributing Cilk Plus wholesale, but consider the
various
parts (spawn/sync, #pragma simd, array notations, elemental functions)
separately.

In summary, I think it's clear we still have some work ahead to prove that
we are serious about making high-quality contributions to Clang that will
benefit the entire Clang community, not just (potential) users of Cilk
Plus.
We are now doing this on several fronts, and you should see more patches
from
us soon. An obvious area that meshes well with the Cilk work is any general
extensions needed to Clang to support any kinds of parallelism extensions.
As
you suggested at the dev meeting, we will be providing those into trunk.

In the meantime, is it feasible to set up a feature branch for Cilk Plus?
I realize feature branches are not all that popular, but they seem to make
sense
for "big things" like this, and it would be very helpful to at least have
our
commits be visible to the community so that we can get feedback as we go
along.
Naturally we would take care of all merging issues and such.

Thank you,

Stefanus