search for: unorthogonal

...ention 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...

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 >

...expect most implementations don't represent the loop explicitly. 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. (There are also other minor differences, e.g. the behaviour of a function-scope-local-addr-space variable in a nested kernel is implementation-defined. See the Notes in the functionQualifiers reference.) david References http://www.khronos.org/registry/cl/sdk/1.1/d...

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

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