How much of OpenCL/C is currently supported by Clang?

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. 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.

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

I agree with what Hal wrote and irrespective of whether I’m developing on OS X, iOS or Linux dealing with more hoops with a cross-platform, platform agnostic language that OpenCL intended to be, only to see it turn into a check list box ala OpenGL seems detrimental to its success overall. It seems to me that ARM, Intel, Apple, ImgTec and others would want to make it as painless as possible.

Just my 2 cents.

  • Marc