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

[Bekket McClane via cfe-dev]

> Anastasia Stulova <Anastasia.Stulova at arm.com> 於 2016年3月20日 下午5:37 寫道：
> 
> 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?

The current approach would transform block into block_literal struct, one of the fields, block_description, contains captured variables.
Another filed in block_literal is the function pointer to the “real” invoke function. The first parameter would always be the pointer to the block_literal instance, where the invoke function can use it to retrieve captured variables. 
Here’s the problem: clang use alloca IR instruction to allocate space for block_literal instance. By default, it would be put on stack. 
So if we move this situation to OpenCL kernel, alloca instruction would put block_literal instance into private address space by default. Then the block instance we pass to enqueue_kernel would need the pointer of block_literal, which is passed as the first argument of the invoke function, to access captured variables but result in failures since the pointer is in private address space. 

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

One of our ideas is to “flatten” all of the captured variables. That is, by the time a block variable is defined, copy all of the captured variables’s value into the invoke function. Since we can determine those variables’ value at that moment (“captured by the Block as const copies” as the spec say).

OpenCL-C’s block is slightly different from the normal one. First, every block variable is const, so each of them need to be defined upon declaration. Second, the “capture”(binding) actions are performed at the time block variables are defined. This would cause a behavior difference:
Here is the pseudo code:

int x = 1;
Block_t myBlock = ^(void)(void){
	print x+1;
};
x = 2;
myBlock();

In the normal circumstance, it would print 3. But in OpenCL-C, since we bind x as constant upon definition, it would print 2. That’s why we think our “flatten” approach could work: Copy captured variables as constants just one time would make a lot easier. 

We’d just come out this idea few days ago, so we haven’t produce any useful code. We’re also considering using builtins to implement this idea.

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

Thank you very much. 
We’re also interesting on your approach. Perhaps we can work on this topic together?

Cheers,

McClane

>  
> 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/20160321/8c968250/attachment.html>