[cfe-dev] OpenCL support

David Neto dneto.llvm at gmail.com
Fri Dec 3 20:14:06 PST 2010


Peter Collingbourne peter at pcc.me.uk
Fri Nov 26 12:21:18 CST 2010

>> tagging with metadata the alloca instructions for __local variables
>
>The way I planned to handle this was to give __local variables with
>function scope a static storage-class, so they would be codegen'd into
>global variables rather than alloca instructions.  This makes the
>implementation easier on the LLVM side as we don't yet have support
>for address space attributes on alloca instructions (remember that
>pointers to __local variables must also be __local).  I implemented
>a patch [2] for this, but decided to wait until the OpenCL semantic
>support in Clang was more mature.
>
>Thanks,
>--
>Peter
>
>[1] http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20101125/b306471a/attachment-0006.bin
>[2] http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101018/035558.html

Peter, I believe it is incorrect to make __local variables static and
therefore codegen'd into global variables.  The reason is that the
storage for a __local variable is shared between different work items
in the same group, but should be different for work items in different
groups.

For consider this:

  __kernel foo(__global int *A) {

     __local x;

     ...

  }

If this kernel is executed as an NDRange with more than one work group
executed in parallel, then the storage for "x" should not be shared
between the two different work groups.  But it should be shared within
the same work group.

I don't know how existing OpenCL implementations handle this case.  It
seems it would be a good idea to transform the code so that uses of x
become loads and stores from memory, and the address for that memory
is returned by a builtin function that itself is dependent on work
group ids.

I'm just learning Clang now, so I'm not prepared to say how that would
be done.  Is it okay to transform the AST before semantic analysis?
Where should I start looking?  (I would guess lib/Sema...)

regards,

David Neto




More information about the cfe-dev mailing list