search for: work_group_size_hint

...uiuc.edu > I think this tends to work better than storing the names of kernels > in a list hanging off from one NamedMDNode: Let me start with (2): > (2) it's not obvious how you're going to extend the list approach to > carry attribute values. Suppose you add support for the work_group_size_hint > (it carries 3 integer values) how are you proposing that the presence of the > attribute and its data be represented? In fact, for the (optional) function attribute qualifiers we use the same approach as you do. If you already know that a function is a kernel, you can concatenate its name...

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

...touch the metadata is if a function with metadata 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...

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 >