[cfe-dev] OpenCL support

[Anton Lokhmotov]

Hi Peter,

> There are several examples of existing attributes in the Clang source
> code which you should be able to follow.  Perhaps you can explain in
> more detail why you cannot use attributes here?

We feared that too much code would be generated when using attributes. (As
you know, we must be cautious of anything negatively affecting the compiler
footprint.)  However, we've re-implemented the kernel function qualifier
using an attribute instead of a field.  Please review.
 

> > +    // OpenCL1.1 enables these extensions by default
> > +    cl_khr_global_int32_base_atomics =
> > +      cl_khr_global_int32_extended_atomics =
> > +      cl_khr_local_int32_base_atomics =
> > +      cl_khr_local_int32_extended_atomics =
> > +      cl_khr_byte_addressable_store = 1;
> 
> I presume you misread Table 4.3 from the spec, which states
> that those extensions must be supported, which is not the same
> thing as being enabled. 

Indeed.  They are disabled now.


> Are you planning to have a mechanism for specifying which extensions
> are supported by a particular implementation?  My initial thoughts
> are that we can add a member function to TargetInfo which returns an
> OpenCLOptions struct containing this information.

Yes, something along these lines.


> > +  unsigned cl_fp_contract : 1; // OpenCL FP_CONTRACT state.
> 
> I'm not sure this should be an OpenCL-specific option.  In future
> we would like to support #pragma STDC FP_CONTRACT, and ideally we'd
> like to be able to reuse OpenCL's FP_CONTRACT support.  I'd suggest
> just making this a Sema field.
...
> You should split this PragmaHandler into separate handlers for
> #pragma OPENCL FP_CONTRACT and #pragma OPENCL EXTENSION.  Then
> there's no need to do the string matching yourself, and it will
> be easier to reuse the FP_CONTRACT support.

Good point.  We've refactored FP_CONTRACT support into a separate
ParseFPContractPragma method.  Note that in OpenCL the default value is ON,
whilst in C99 it is undefined.


> Comments on the second patch to come...
I'm attaching it again for convenience...


Many thanks,
Anton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00002-keywords.patch
Type: application/octet-stream
Size: 13303 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101222/58b20323/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00001-kernel-extensions-pragmas.patch
Type: application/octet-stream
Size: 16058 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101222/58b20323/attachment-0001.obj>