[cfe-dev] OpenCL parsing / type support

[Anton Lokhmotov]

> From: Chris Lattner
> Sent: 11 March 2010 18:05
> 
> I'm fine with improving infrastructure to support this, but there is no
> reason to add first class language support for things like __kernel.
> It just makes the compiler more complex for no reason.  If you're
> interested in driving this, a better thing to focus on would be to
> provide an implementation of the *implicit include* which provides the
> #defines etc.
Yes, I'm interested in driving this.  I didn't mean to suggest that an implicit header is necessarily a bad idea.  I agree that the things that can be supported this way, such as vector types and address (and hopefully function) qualifiers, should be supported this way.  Where do you think such a header should live (e.g. which subdirectory of Clang)?

It appears, however, that certain things cannot be supported only with headers.  For example, the OpenCL standard restricts usage of the half type (16-bit floating point) to declaring a pointer to a buffer that contains half values; such pointers cannot be dereferenced.  In other words, half behaves similar to void.  However, sizeof(half) must be 2.  (Obviously, if someone knows an ingenious quirk to solve this conundrum, I'd be interested to hear.) 

The standard also specifies many restrictions which the compiler should check as semantic analyses, possibly in a few separate passes.  Also, there are some alignment restrictions which perhaps call for a special OpenCL triple (since the target should be OpenCL-compliant)?

I'm new to Clang, so I'd appreciate your thoughts on how to implement OpenCL support properly.


> From: Sebastian Redl
> Sent: 11 March 2010 14:34

> > 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!
> 
> This shouldn't matter. Identifiers containing double underscores or
> starting with an underscore and an uppercase letter are not valid
> identifiers for user code under any circumstances.

Perhaps I've exaggerated the problem a bit but still extensions' keywords should not be listed as KEYALL ;).

Cheers,
Anton.