Yet Another Thing I Don’t Know about CUDA:
Suppose I have a kernel with a handful of pointer arguments (obviously to device memory):
e.g. kernTest(int x, int y, int z, int *a, int *b, float *fa, float *fb) {
…
}
I am confident that x, y and z won’t be aliased by any of the pointer arguments, as they will be allocated in shared memory, and the device memory copies have been done explicitly in host code. However, what about the relationship among a, b, fa and fb?
The CUDA kernel code has no way of knowing what their aliasing relationship is: there’s nothing to stop me from setting a=b and fa=fb or, for that matter b = &a[73] and fb = &fa[69]. Is there?
I can’t help but think that there are a number of possible optimizations that might be suppressed by this uncertainty.
It is possible - but not done yet - to analyze the host code to detect these relationships. This would be pretty awkward, though, as the flow of analysis information from host → kernel compiles doesn’t have any particularly clear path.
What would be more helpful in the short term is the C99 keyword ‘restrict’, that would allow the programmer to guarantee non-aliasing between pointer arguments to the kernels. While ‘restrict’ is pretty fiddly, at least you’d only have to use it at the API boundary between host and kernel code…
Thoughts? Am I missing something? (perhaps some regulation that you don’t alias these pointers already…)
Geoff.