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

Liu, Yaxun (Sam) via cfe-commits cfe-commits at lists.llvm.org
Fri Nov 4 08:06:40 PDT 2016


Even if we use string for address space MD, we still need to define them somewhere. On the other hand, if we use SPIR enum, we just need to refer to the SPIR spec in the documenting comments.

Sam

-----Original Message-----
From: Pekka Jääskeläinen [mailto:pekka.jaaskelainen at gmail.com] 
Sent: Thursday, November 03, 2016 4:24 PM
To: pekka.jaaskelainen at gmail.com; Stellard, Thomas <Tom.Stellard at amd.com>; anastasia.stulova at arm.com; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>
Cc: alexey.bader at intel.com; xiulipan at outlook.com; cfe-commits at lists.llvm.org; Ding, Wei <Wei.Ding2 at amd.com>
Subject: [PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

pekka.jaaskelainen added a comment.

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D26157





More information about the cfe-commits mailing list