[cfe-dev] OpenCL patch

[Speziale Ettore]

Hi,
I'm a Ph.D. student from Politecnico di Milano. I'm helping Alberto
during its master thesis.

> Anton Lokhmotov (ARM) has already submitted a patch for address space
> attributes which seems closer to being correct, so you may want to
> restrict this patch to the __kernel attribute.

I've seen Anton have re-submitted its patches. Alberto patches seem to
be a sub-set of Anton patches, so I think is useless to work on
Alberto's patches if Anton patches will be accepted.

> We may want to pick and choose certain declarations from stddef.h and
> stdint.h for this, or just #include both of them (I'm not sure if the
> namespace pollution is important).

OK.

> > At the moment the provided test cases fails due to the presence of the
> > aka construct in
> > the diagnostic messages, it unrolls the typedef showing the canonical
> > type which depends
> > on the current architecture.
> 
> That's because types like Ctx.getSizeType() are in fact the native
> types (not typedefs) for the current target.  When you perform tests
> like this:
> 
> > +              || Ctx.hasSameType(Ctx.getSizeType(), ParamType)
> > +              || Ctx.hasSameType(Ctx.getPointerDiffType(), ParamType)
> > +              || Ctx.hasSameType(Ctx.getIntPointerType(), ParamType)
> > +              || Ctx.hasSameType(Ctx.getUnsignedIntPointerType(), ParamType))
> 
> you are in fact testing that the canonical types are equivalent,
> effectively preventing integer types which happen to match these
> particular types from being used.

My error! Later, thinking about patches, I've arrived at the same
conclusion, but I hadn't access to Internet for few days and so I can
admit the mistake only now.

> If you want to disallow these typedefs in kernel parameters
> a better approach may be to add a 'kernel poison' attribute on
> their typedefs and to recursively check for the poison attribute
> in HandleOclKernelAttr.

Good, thank you for the explanation. I think we can start working on
this, using Anton's patches as base -- He don't perform signature
checking. This allow to focus work on a small area, allowing to known
how to write good code for Clang.

Politecnico objective is to build an opencl compiler. I think is better
to hack on clang, because (1) we can learn a lot from a
production-quality compiler, (2) students can see a real compiler
implementation and (3) we will not build another opencl compiler.

Maybe we can coordinate our work, in order to exploit available
resources. Our technical experience is not at clang level, but we want
to improve our skills.

What do you think?
Hi,
speziale.ettore at gmail.com