[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.
Thanks,
--
Peter
More information about the cfe-dev
mailing list