yaxunl marked 10 inline comments as done.
yaxunl added a comment.
In https://reviews.llvm.org/D38134#880133, @Anastasia wrote:
> I think we should add a test case when the same block is both called and
> enqueued.
Will do.
================
Comment at: test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl:3
+
+// CHECK: %[[S1:struct.__amdgpu_block_arg_t.*]] = type { [3 x i64], [1 x i8] }
+// CHECK: %[[S2:struct.__amdgpu_block_arg_t.*]] = type { [5 x i64], [1 x i8] }
----------------
Anastasia wrote:
> yaxunl wrote:
> > Anastasia wrote:
> > > This struct is not identical to block literal struct?
> > The LLVM type of the first argument of block invoke function is created
> > directly with sorting and rearrangement. There is no AST type corresponding
> > to it. However, the function codegen requires AST type of this argument. I
> > feel it is unnecessary to create the corresponding AST type. For
> > simplicity, just create an AST type with the same size and alignment as the
> > LLVM type. In the function code, it will be bitcasted to the correct LLVM
> > struct type and get the captured variables.
> So `void ptr` won't be possible here? Since it is cast to a right struct
> inside the block anyway. Once again a block is a special type object with
> known semantic to compiler and runtime in contract to kernels that can be
> written with any arbitrary type of arguments.
>
> I just don't like the idea of duplicating the block invoke function in case
> it's being both called and enqueued. Also the login in blocks code generation
> becomes difficult to understand. So I am wondering if we could perhaps create
> a separate kernel function (as a wrapper) for enqueue_kernel which would call
> a block instead. What do you think about it? I think the kernel prototype
> would be fairly generic as it would just have a block call inside and pass
> the arguments into it... We won't need to modify block generation then at
> all.
Will emit a wrapper kernel which calls the block invoke function and keep the
block invoke function unchanged.
https://reviews.llvm.org/D38134
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
