[LLVMdev] Function-level metadata for OpenCL (was Re: OpenCL support)

[Peter Collingbourne]

On Fri, Dec 17, 2010 at 04:21:18PM -0500, David Neto wrote:
> 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 as a kernel.  It
> seems a handy place to hang it, but is it really exclusive of the
> other calling conventions?
> In particular, does that approach nicely in the case where a CPU is
> running the kernels?  Does that lead to special casing or duplication
> in the code generator?  For example, you still have to know what
> "real" calling convention to use when a kernel is running on a CPU.
> (Forgive my ignorance.)

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 pointer to
__local memory space, which would not be necessary on GPUs.  Then in
fact you would use a standard calling convention on a CPU.

But for GPUs, I think using the calling convention is appropriate.
If we standardise the calling convention number, this can be the
default behaviour.

> I would be happy to see an OpenCL-specific patch that always marked
> non-kernel functions with internal linkage.  Then you could
> distinguish the kernel/non-kernel case just by the linkage attribute.
> It might be a little unclean / unorthogonal, but I think it would be
> ok.

Some OpenCL implementations (including my own) may use runtime library
functions which live in a separate compilation unit.  These would
need to be marked external but of course would not be kernel functions.

Nick Lewycky wrote:
> Being discardable is a design point of metadata. You might add something
> else to support this, but it won't be metadata.

There's nothing intrinsic about the concept of metadata which requires
it to be discardable.  In particular, if the metadata is attached to
a function, the only case I can think of where an optimiser needs
to 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 mean to the optimizers
> and code generator?

For PTX, if __kernel is set on a function it needs to be codegen'd
with a specific directive which marks it as a kernel entry point.
What this actually means at a lower level I don't know (the low level
machine code representation is undocumented).  I believe there is
also something similar in the AMD Stream IL.

As for the other attributes mentioned above, I don't know off-hand,
but I believe there are PTX directives for at least some of them.

> Could you just make __kernel mean "externally visible" and undecorated
> functions be "linkonce_odr"?

I think the semantics of undecorated functions is closer to "internal"
than "linkonce_odr" here (kernel programs shouldn't be able to
provide a definition for functions in another module, such as a
runtime library module).

> If that's not enough, could you swing it around
> and maintain single named metadata node with a list of functions that are
> marked __kernel?

Are you saying that named metadata nodes are non-discardable?  Even
if this were true, it would still be difficult to represent the other
attributes unless the metadata were attached to the function.

Thanks,
-- 
Peter