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

[Anton Lokhmotov]

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.