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

[Anastasia Stulova via cfe-dev]

Hi David,

> It sounds as if OpenCL’s requirements are much simpler than [Objective-]C’s.  I looked at implementing flattening for blocks a few years ago, but it becomes quite complex when a single variable is bound to multiple blocks and the potential performance improvements did not justify the increased complexity.  This is not an issue for you though.

We can still have some sort of multiple binding via function parameters though, for example:

typedef int (^block_t)();

void f1(block_t bl) {
  int i = bl(); // this calls bl1, bl2 and anonymous blocks expr below
}

void f2(int i) {
  const block_t bl1 = ^{return i+1;};
  const block_t bl2 = ^{return i+2;};
  f1(bl1);
  f1(bl2);
  f1(^{return i+3;});
}

However, they are all known (can be deduced) at compile time. It still creates some complications. I am not sure how flattening would work for dynamic parallelism, but something to note, we can have non-compile time known captures too (see i in this example). And the sematic is to be able to spawn the enqueued blocks anywhere in the device with potentially isolated memory areas. 

> It sounds as if OpenCL’s blocks are actually far closer to C++ lambdas with a default copy capture than they are to [Objective-]C blocks.  It might be cleaner and simpler to treat them as special syntax for lambdas than as special semantics for blocks.

Yes, the use of blocks in OpenCL is semantically closer to C++ lambdas. I wish there would be easier ways to share C and C++ parts in the compiler. We might still look into it later though.

Thanks,
Anastasia

-----Original Message-----
From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall
Sent: 21 March 2016 08:26
To: Bekket McClane
Cc: Anastasia Stulova; cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] About OpenCL 2.x Dynamic Parallelism

On 20 Mar 2016, at 16:19, Bekket McClane via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
>> 
>> 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. 

In [Objective-]C, If the block is expected to persist beyond the lifetime of the caller, then the callee is expected to call _Block_copy to promote it to the heap.  The compiler emits copy helpers (and descriptors for captured variables that have trivial copy semantics) that allow this to work with a little bit of support from the blocks runtime library.

For OpenCL, you may want to generalise this slightly to provide different target address spaces for the copy, but note that for __block to work correctly the target address space must be readable (and writeable) in the context of the caller.  If you do not support __block variables then this is not an issue.


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

It sounds as if OpenCL’s requirements are much simpler than [Objective-]C’s.  I looked at implementing flattening for blocks a few years ago, but it becomes quite complex when a single variable is bound to multiple blocks and the potential performance improvements did not justify the increased complexity.  This is not an issue for you though.

It sounds as if OpenCL’s blocks are actually far closer to C++ lambdas with a default copy capture than they are to [Objective-]C blocks.  It might be cleaner and simpler to treat them as special syntax for lambdas than as special semantics for blocks.

David