Abstract:
This message is in response to messages by Krister Wombell and Mike Gist,
and contains a question to Chris Lattner and Devang Patel.
From: Krister Wombell [mailto:kuwerty at gmail.com]
Sent: 23 December 2010 14:10
To: Anton Lokhmotov
Cc: Peter Collingbourne; cfe-dev at cs.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 with an attribute name, check if the attribute's
metadata are present (and then obtain the attribute's value(s)).
> (1) passes can just concatenate the name of the function with a postfix
and> look up the metadata, there's no second phase of then searching through
a
list> to find the name of the function it's interested in.
We've taken a different view on this. At the moment, I can think of 3 cases
when kernel information can be required:
a) clCreateKernel() is called with a kernel function name. The compiler
needs to look-up metadata for this particular function, because if the
function is not a kernel the user must get an CL_INVALID_KERNEL_NAME error.
In this case, your approach is superior because you don't have to search the
list (or about the same if the list has only one entry :))
b) clCreateKernelsInProgram() is called. The compiler then needs to find
the names of all kernel functions. Given that this call can happen after
linking against the built-in function library, the module can contain tens
to hundreds different functions, of which only a handful will be kernel
functions. In this case, our approach is superior.
c) You may need to find out if a kernel function being compiled has another
kernel function in its call tree. For example, if the other kernel function
has any variables in the __local address space, the compiler may want to
issue a warning that the behaviour is implementation-defined. Again, your
approach is superior.
In summary, since we expect the kernel name list to be short, we tolerate
list searchers in the cases (a) and (b), because we avoid potential
inefficiency in the case (b). Does it make sense?
-----Original Message-----
From: Mike Gist [mailto:Mike.Gist at imgtec.com]
Sent: 22 December 2010 09:59
To: Anton Lokhmotov; Peter Collingbourne; David Neto; nlewycky at google.com
Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> I still don't think that metadata is the right approach for recording
> certain CL specific function attributes. The blog entry that Chris and
> Devang wrote back in March detailing metadata makes it quite clear that
> metadata shouldn't be used for anything that can't be discarded at
whim.
> So I'm nervous about adding anything that 'breaks' this design
decision,
> without actually making the decision to change that design (which
> probably needs input from the original authors).
Given that at least two companies have found metadata useful for
representing OpenCL C features in LLVM-IR, I think the community needs to
reconsider the use of metadata, perhaps introducing a 'sticky' variant
of
it?
Chris, Devang, what are your thoughts on this?
Anton.
