[cfe-dev] OpenCL patch

Peter Collingbourne peter at pcc.me.uk
Thu Jan 6 09:37:28 PST 2011

Hi Speziale,

On Fri, Dec 24, 2010 at 02:35:30PM +0100, Speziale Ettore wrote:
> 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.

What I meant by this is that the type checking aspect of this patch
can be reworked to be built on top of ARM's __kernel attribute patch,
as you pointed out below.

> > 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.

Here at Imperial there is at least 1 other person working on an OpenCL
implementation.  We stand to benefit from OpenCL support in Clang;
at least for my work, production-quality is important in order to
work with real-world kernels.

> 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.

It may be best to coordinate with ARM on this, as they are taking
the lead on the implementation work.  I am happy to code review any
proposed patches.


More information about the cfe-dev mailing list