Anastasia added a comment.
Now if we have a block which is being called and enqueued at the same time,
will we generate 2 functions for it? Could we add such test case btw?
I feel it would be much simpler if we could always generate the kernel metadata
for blocks. A lot of special case code would be removed if we do this. OpenCL
doesn't prevent kernel functions to be used just as normal functions (6.7.1) so
it should be a perfectly valid thing to do. Do you seen any issues with that?
================
Comment at: lib/CodeGen/CGBlocks.cpp:1255
// Allocate a stack slot to let the debug info survive the RA.
- Address alloc = CreateMemTemp(D->getType(), D->getName() + ".addr");
+ Address alloc = CreateMemTemp(
+ !PV.isIndirect() ? D->getType()
----------------
Is there any test that covers this?
================
Comment at: lib/CodeGen/CGOpenCLRuntime.cpp:113
+
+llvm::Value *CGOpenCLRuntime::emitOpenCLEnqueuedBlock(CodeGenFunction &CGF,
+ const Expr *E) {
----------------
I am not particularly in favour of duplicating CodeGen functionality as it
typically has so many special cases that are hard to catch. Is this logic
needed in order to pass to block literal information that the block is
enqueued?
================
Comment at: lib/CodeGen/CodeGenFunction.cpp:535
+ if (i == 0 && IsBlock) {
+ ty = CGF.CGM.getTargetCodeGenInfo().getEnqueuedBlockArgumentType(
+ ASTCtx, *CGF.BlockInfo);
----------------
I don't quite understand why we need to special case this? As far as I
undertsnad block argument is a `generic void* ` type but it's being cast to a
concrete block struct inside the block function. Do we gain anything from
having it a specific type here?
https://reviews.llvm.org/D38134
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
