[cfe-dev] About OpenCL 2.x Dynamic Parallelism

Anastasia Stulova via cfe-dev cfe-dev at lists.llvm.org
Sun Mar 20 02:37:39 PDT 2016


Hi Bekket,

> There is a field in block_literal called "isa" representing the type of this block. But this field seems to always set to external symbols starts with "_NS", which is Cocoa's symbols. Is this necessary?

This is not required for OpenCL, but we reuse ObjC implementation as much as possible at the moment. Of course, it doesn’t mean it can’t be change for OpenCL.

> But it seems that this approach doesn't work well with CL language since it's hard to handling the address space of block_literal instances.

Could you elaborate here what your problem is exactly? Would adding address spaces in generated IR help?

> Last but not the least, Is there anyone working on implementing dynamic parallelism? There seems to be no discussions about that on this mailing list.

We are working on this now. There were two commits to blocks diagnostics past weeks and I am planning to setup the review on enqueue_kernel builtin upcoming weeks. I am not aware of any work on blocks codegen to IR though. Is there anything in particular you need?

Also if you have any code you think might be useful to open source Clang that adds new functionality or improves existing work on this topic and you are happy to share, do let me know.

Cheers,
Anastasia
From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Bekket McClane via cfe-dev
Sent: 17 March 2016 02:52
To: cfe-dev at lists.llvm.org
Subject: [cfe-dev] About OpenCL 2.x Dynamic Parallelism

Hi,
Our lab is working on compiling opencl 2.x into NVPTX
But we have encountered some problems in dynamic parallelism. Blocks, particularly.
In short, clang would try to use Objective-C's approach to compile blocks in CL code.
It would generate block_literal struct to hold block information and block_descriptor to hold captured variables.

My first question is:
There is a field in block_literal called "isa" representing the type of this block. But this field seems to always set to external symbols starts with "_NS", which is Cocoa's symbols. Is this necessary?

Second, clang put captured variables in block_descriptor and passed the entire block_literal, which also contains a field holding pointer to a block_descriptor instance, as a implicit "0 th" arguments for the real invoked function. But it seems that this approach doesn't wok well with CL language since it's hard to handling the address space of block_literal instances.
We have an idea passing all of the captured variables as function arguments, by value, for the invoked function. What do you folks think?

Last but not the least, Is there anyone working on implementing dynamic parallelism? There seems to be no discussions about that on this mailing list.

Best Regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160320/7d00dc31/attachment.html>


More information about the cfe-dev mailing list