[cfe-commits] Cilk Plus Extension for Clang

[Richard Smith]

On Tue, Nov 6, 2012 at 10:04 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "Chandler Carruth" <chandlerc at google.com>
>> To: "Wei Pan" <wei.pan at intel.com>
>> Cc: cfe-dev at cs.uiuc.edu, "llvm cfe" <cfe-commits at cs.uiuc.edu>
>> Sent: Tuesday, November 6, 2012 2:55:31 AM
>> Subject: Re: [cfe-commits] Cilk Plus Extension for Clang
>>
>> 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.
>
> 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 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.