[cfe-dev] [cfe-commits] Cilk Plus Extension for Clang

[Chandler Carruth]

On Thu, Nov 1, 2012 at 10:09 AM, Pan, Wei <wei.pan at intel.com> wrote:
> 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.

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.