bader added a comment. In https://reviews.llvm.org/D36410#855282, @Anastasia wrote:
> Ok, I will update it to be implicitly generic then. Just to be sure, @bader > do you agree on this too? > An alternative approached could be (in case we want to allow this code) to > **assume captures are located in the generic AS implicitly**. However, in > this case programmers should be advised that erroneous AS casts can occur > further that can't be diagnosed by the frontend (i.e. if capture address is > used further in the operations of a different address space to where the > captures physical location is). I don't have a strong opinion on this topic, but I'm worried about relying on implicit assumptions, which might make code less portable. How the alternative approach is this suppose to work for enqueue_kernel? Do we assume that the captured variables passed by generic pointer and compiler will assign the correct address space based on the explicit casts in the block? There are some restrictions on kernel parameters: 6.9.a. Arguments to kernel functions declared in a program that are pointers must be declared with the global, constant or local qualifier. > I feel forbidding user taking address of captured variable is too restrictive > and make blocks less useful. I have no information how widely blocks are used by the OpenCL community and how important this feature is. https://reviews.llvm.org/D36410 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
