On Tue, Nov 6, 2012 at 10:04 AM, Hal Finkel <[email protected]> wrote: > ----- Original Message ----- >> From: "Chandler Carruth" <[email protected]> >> To: "Wei Pan" <[email protected]> >> Cc: [email protected], "llvm cfe" <[email protected]> >> 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 <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
