[cfe-dev] OpenCL C

[Erik Schnetter]

On Dec 17, 2013, at 11:44 , Renato Golin <renato.golin at linaro.org> wrote:

> On 17 December 2013 16:35, David Tweed <david.tweed at gmail.com> wrote:
> I'll note that all those issues primarily of big import to a back-end (or possibly a complete compiler). The situation with common, open-source OpenCL is it is primarily in terms of modifications to the clang front-end to be able to generate fully accurate AST's for OpenCL and ot issue correct and informative diagnostics. It would be useful to see what sort of consensus the community arises as to what ought to be being done for this case: for a front end I suspect it's going to be generating a lot more test cases to ensure features can only be used where the OpenCL specifications allow them to be.
> 
> AFAIK OpenCL doesn't have a concrete specification, or the one you have is not concrete enough in some places, and too concrete in others.
> 
> You can create perfectly valid Dwarf that no debugger in the world can digest. You can create perfectly valid ELF objects that won't link with others. You can parse C++ into a parfectly valid AST, but if you can't build proper (target-specific) IR from it, it's useless.
> 
> For instance, if there is an official (Kronos-certified) parser that tells you whether a piece of OpenCL IR/AST conforms to the standard, that's a starter. If there is an emulator that executes OpenCL on the CPU as if it were some GPU, that's better. If there is a standard CPU implementation that will be actually used in production (like the Intel one), that's a lot better.
> 
> But without any of these, I can't see how can we say something is "supported".

OpenCL C is a language, same as C or C++ or Objective C. There is a well-defined standard that is so close to C that it actually mostly describes the differences to C, and I assume that in practice this is the most useful thing to do to ensure clang treats it correctly. A C compiler doesn't need to provide an implementation of sqrt() or system(), and in fact clang doesn't -- and thus, and OpenCL C compiler doesn't need to provide a library either.

OpenCL C runs just fine on all platforms, including CPUs and GPUs, and no GPU emulator is needed to run it on CPUs or to examine correctness.

Think of OpenCL C as C, with explicit support for vector data types added (i.e. a better syntax for attribute((ext_vector_type(n)))), and where the sizes of the standard data types (short, int, long, float, double) are defined by the standard and not left to the implementation. Most other changes are minor, or refer to the standard library only.

I think OpenCL C is ready to be a first-class language in clang.

-erik

-- 
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131217/4d15219d/attachment.sig>