[PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

[Anastasia Stulova via cfe-commits]

Anastasia added a comment.

In https://reviews.llvm.org/D26157#586867, @pekka.jaaskelainen wrote:

> Indeed, it requires wider scale discussion to get it right, and e.g. to pass the info to AA. But to be honest, I think OpenCL and CUDA are still considered 'minority' languages in Clang/LLVM which makes me usually lean towards least intrusive implementation solutions whenever possible.
>
> The matter was discussed 5 years ago: http://clang-developers.42468.n3.nabble.com/OpenCL-Address-Spaces-and-Runtimes-td2814865.html
>
> The current situation of having the target AS in the MD is clearly not the way to go due to the loss of info for flat AS machines, so I think this discussion should be mostly about what should those designated IDs be.
>
> Sure, we could use strings such as "opencl.global" there instead, but I'm not sure how much that adds value to simply having known integer IDs instead. SPIR 1.2-2.0 is based on LLVM and designed to store info of OpenCL C kernels, therefore I thought the SPIR IDs are logical as we can just refer to SPIR specs in this case. Other alternative might be to retain the Clang's logical IDs, but I recall there was some special semantics/handling for AS IDs > 255. I might be wrong though.


Actually the solution from Ettore looks like a good compromise to me to what we've discussed so far being more generic than hard-coded numbers but less heavy than putting strings for each kernel.

However, I also see that the issue is in absence of common agreement and understanding of the compiler flow which perhaps is also due to absence of any documentation (I am hoping to improve). I still think that this particular problem originates from the fact that compiler removes relevant source information too early. It seems to me that the compiler has to keep the AS information as late as possible until it's no longer being used anywhere in the toolchain. In this case if this is being queried by RT, it expects that this information is relevant for some reason (i.e. for example to optimize for a particular target architecture). So if there are no memory segments, nothing can be done to optimize for this and therefore providing the "fake" segment information doesn't seem to be useful? I am just trying to understand the use case.

I am not too picky on the exact implementation details here. Perhaps well documented hard coded numbers should work too. I am just trying to see the use case for this and whether the current compilation flow is suboptimal to support it properly. But perhaps also the issue is that those MDs are OpenCL specific anyways, but the IR itself is supposed to be source language agnostic.


Repository:
  rL LLVM

https://reviews.llvm.org/D26157