[cfe-dev] OpenCL parsing / type support

[Arnaud Allard de Grandmaison]

I just have a patch for the address space not for kernels.

The goal is to be able to qualify the pointer parameters of intrinsics function with an address space. This is done by adding a number as a postfix to the '*' modifier in clang/Basic/Builtins.def. I have not invented anything there, as I have seen this in a opencl/llvm presentation.

This way, you can now have a memcpy-like function, transferring blocks from address space 0 to 1, with the following declaration in your clang/include/clang/Basic/BuiltinsZZZZ.def:

BUILTIN(__builtin_memxfer, "v*1v*1vC*z", "n")

Clang/head is currently broken (building it fails with 'llvm::DIFile' has not been declared), so I have not been able to test it, but the patch applies and the patched files compile just fine.
--
Arnaud de Grandmaison

-----Original Message-----
From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Anton Lokhmotov
Sent: Thursday, March 11, 2010 12:18 PM
To: cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] OpenCL parsing / type support

I am also looking into OpenCL support in Clang, and am learning quite a few
of hacks Chris and Arnaud are referring to.  It would be good, however, to
implement OpenCL features properly, so that setting LangOpts.OpenCL=1 would
just work.  I suggest we make a conscious community-wide effort here so that
various implementations do not reinvent the wheel. (So Arnaud it would be
great if you could contribute to Clang head your patch for address space and
kernel attributes!)

Right now I'm staring into TokenKinds.def.  One issue there is the use of
KEYALL for

a) non-C99 (and hence automatically non-OpenCL) keywords (e.g. __func__)
b) GNU extensions (e.g. _Decimal32, __builtin_choose_expr)
c) MS extensions (e.g. __forceinline and __declspec).

This means that a Clang-based OpenCL front-end may not accept these as valid
identifiers, although the standard does not list them as keywords!  It's
easy to make existing keywords valid for OpenCL but it's not so easy to
exclude them (e.g. valid in almost all C variants but invalid in OpenCL).

I appreciate many people are busy with preparing for release 2.7 but this is
something we should address sooner rather than later.

Anton L.


_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: intrinsics+addrSpace.patch
Type: application/octet-stream
Size: 1077 bytes
Desc: intrinsics+addrSpace.patch
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100311/b0d7a52f/attachment.obj>