[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