[cfe-dev] How much of OpenCL/C is currently supported by Clang?

[Hal Finkel]

On Tue, 7 Aug 2012 23:40:32 +0100
"Anton Lokhmotov" <Anton.Lokhmotov at arm.com> wrote:

> Hi Phillip,
> 
> > I'm trying to determine with some precision how much of OpenCL/C is
> > currently implemented by Clang? I find scattered posts and
> > references to simple examples and submissions/patches but nothing
> > comprehensive. Wouldn't something along the lines of the C++11
> > status webpage be useful?
> 
> Having an OpenCL C 'dashboard' is an interesting idea.  The question
> is who is going to compile and maintain it, and according to which
> criteria.
> 
> At ARM, we have several hundred OpenCL-specific tests (many of which
> have combinatorial coverage leading to thousands of tests).  Our
> Clang-based frontend passes all the tests but relies on a large
> number of patches to mainline Clang.  Out of interest, we could
> disable our patches and measure the pass rate (the number of tests
> that would still pass divided by the number of all tests).  I could
> even tell you what the pass rate was for broadly defined categories
> of tests, but I'm not sure how useful that would be without showing
> you the actual tests...
> 
> > It seems that a clear description of what is and isn't currently
> > implemented would save redundant effort of people trying to figure 
> > this out and help converge on a complete implementation by focusing 
> > would-be contributors on what remains.
> 
> IMO, any efforts on implementing OpenCL C features that are currently
> missing from Clang should better be used on reviewing.  ARM, Intel
> and Apple already have fully conformant implementations, and are all
> willing to contribute their patches to mainline Clang. 

I understand what you're saying, but there is something about this that
seems immensely silly. Not only are the three of you (if not others)
duplicating work, but the result is less-than-complete public tools
environment for dealing with OpenCL codes. A number of us in
high-performance computing are deeply concerned about fighting vendor
lock-in with accelerator-based codes, and use of OpenCL over other
proprietary languages would be a great step in the right direction.
Unfortunately, the largest force directing new codes toward proprietary
languages is the enhanced tool support for those languages (driven by
their currently-larger market share). To increase the use of OpenCL we
need to lower the barrier of entry for OpenCL-capable tools, and making
the open-source version of clang fully compliant would be a huge step
in the right direction.

 -Hal

> It's just
> that the implementers and the reviewers have limited bandwidth and
> somewhat misaligned priorities. For example, I may want to
> open-source code for a feature that's particularly painful to
> maintain first, but even fellow implementers may not be interested in
> this feature if supporting this feature is optional...
> 
> So, if you are interested in improving OpenCL C support in Clang, I
> suggest you request a particular feature that you need via this list,
> and we will try to respond quickly with a patch for that feature.  In
> this way, both the implementer and the reviewer will be perfectly
> aligned in their desire to see support for this feature in mainline,
> which should lead to faster review cycles and acceptance decisions.
> We can even populate the dashboard as we go, marking features that
> are deemed complete.
> 
> Does it make sense?
> 
> Best regards,
> Anton.
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory