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

Nick Lewycky nlewycky at google.com
Fri Dec 17 14:16:16 PST 2010


On 16 December 2010 14:33, Peter Collingbourne <peter at pcc.me.uk> wrote:

> 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
> > differently the kernel qualifier and optional kernel qualifiers, which
> > require storing <typen> and X, Y, Z values. (I don't even want to think
> how
> > one would mangle the optional qualifiers into a kernel name and then
> > demangle.)
> >
> > That's why we propose to use metadata for this purpose.  Does anyone have
> a
> > better idea?
>
> I agree that metadata should be used for function qualifiers;
> a prerequisite being support for non-discardable function-level
> metadata, which would need to be added to LLVM.  I'm undecided on
> whether __kernel should also be represented by metadata; there is
> precedent (PTX backend) for using the calling convention.
>

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

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?

Could you just make __kernel mean "externally visible" and undecorated
functions be "linkonce_odr"? 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?

Nick

I do have a concern though with the semantics of the inliner when it
> needs to inline a function with metadata.  One possibility would be to
> discard the callee's metadata, or somehow merge it with the caller's.
> Discarding seems like the right solution for OpenCL and a good starting
> point (in future we may wish to add attributes to metadata nodes like
> the 'appending' linkage for globals) but sounds like something that
> should be discussed first.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101217/a009d416/attachment.html>


More information about the llvm-dev mailing list