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

[Marc J. Driftmeyer]

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

On 08/08/2012 07:26 AM, Hal Finkel wrote:
> 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
>
>

-- 
Marc J. Driftmeyer
Email :: mjd at reanimality.com <mailto:mjd at reanimality.com>
Web :: http://www.reanimality.com
Cell :: (509) 435-5212
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120808/ef74a5ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjd.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120808/ef74a5ec/attachment.vcf>