[cfe-dev] OpenCL and Type Poisoning

John McCall rjmccall at apple.com
Wed Jan 26 12:01:44 PST 2011

On Jan 26, 2011, at 11:54 AM, Peter Collingbourne wrote:

> On Wed, Jan 26, 2011 at 10:58:04AM -0800, Chris Lattner wrote:
>> On Jan 26, 2011, at 10:41 AM, John McCall wrote:
>>> On Jan 26, 2011, at 12:02 AM, Speziale Ettore wrote:
>>>> I have tried to implement an "openlcl_kernel_poison" pragma, but I've
>>>> seen that the pragma construct is too far from what I want to do. Thus,
>>>> I've tried to implement the same think with an attribute:
>>>> typedef long size_t __attribute__((opencl_kernel_poison));
>>> Having an attribute on typedefs makes sense to me.  It does not make
>>> any sense as a type qualifier;  among other things, it's a property of types,
>>> not something that makes a different type.
>>> I don't think the OpenCL poisoning semantics are generic enough to be
>>> worth supporting in the standard compiler.
>> I agree.  For constraints like this, it is best for an opencl compiler to walk the parsed AST and do custom validity checks as an AST walk.  There is no need to do this as part of Sema.
> Hm?  I'm confused here.  This behaviour is part of the spec, and if
> we claim to support OpenCL we should try to support this behaviour.
> If not, where should we draw the line between semantic checks which are
> done by Clang and those which are done by a specific implementation?

If we know at declaration time which functions are kernels — we do, right?
I know next to nothing about OpenCL — then I think it's reasonable to do this
in Sema as a check during the declaration of kernels.

My comment about "not worth supporting in the standard compiler" was poorly
phrased.  I just meant that the semantics here — certain types are forbidden
in certain positions in the parameter lists of certain kinds of functions —
is not nearly generic enough to try to generalize to a non-OpenCL attribute.


More information about the cfe-dev mailing list