search for: reqd_work_group_size

...l calling another kernel. I like this idea. I think that the entry point should keep its original name though, while we rename the body, because the fact that we factor out the function body seems like an implementation detail. To a certain extent it also removes the need to attach metadata for reqd_work_group_size etc at the function level (if required by the target), since this information can be attached to intrinsic calls within the entry point. Example: define void @foo() nounwind { entry: call void @llvm.opencl.reqd.work.group.size(i32 4, i32 1, i32 1) ; .. other setup .. call void @foo_kernel()...

Sorry for the late reply, as I have been on vacation for awhile. One method which I haven't seen mentioned is to separate out the kernel semantics from the function definition. All the kernel attribute does is specify that this function is an entry point to the device from the host. So, why not just create a separate entry point that is only callable by the host and everything from the

However we record the fact that a function is a kernel, the mechanism should handle the case of a kernel calling another kernel. Recall that a kernel called by another kernel behaves more like a regular function. For example it doesn't have workspace iteration automatically applied to it; rather it just adopts the work item of the caller. About using a calling convention to mark a function

On Tue, Dec 21, 2010 at 07:17:40PM -0000, Anton Lokhmotov wrote: > > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > > Sent: 20 December 2010 20:11 > > As with __local variables, it may be that "kernelness" cannot be > > represented in a standard form in LLVM. For example on a CPU a > > kernel function may have an additional parameter which is a

...ata is inlined. And as I mentioned in my previous mail I don't think this will be any trouble for OpenCL. The __kernel attribute isn't the only attribute we need to preserve. There are also: __attribute__((vec_type_hint(type))) __attribute__((work_group_size_hint(X, Y, Z))) __attribute__((reqd_work_group_size(X, Y, Z))) which provide hints to the code generator regarding the specific work load of a particular kernel. > Why are you trying to preserve "kernel"-ness into the LLVM IR? What > semantics does it have? What does __kernel actually mean to the optimizers > and code generator...

On Thu, Dec 16, 2010 at 06:16:25PM -0000, Anton Lokhmotov wrote: > Mike Gist wrote: > > You could also consider placing all kernel functions in a 'kernel' > > section, or adding a function attribute for kernels. > Unlike in Clang, function attribute bit-fields in LLVM are pretty crowded > (only couple of bits are unused?). Besides, we do not want to represent >