[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D156816#4551357 <https://reviews.llvm.org/D156816#4551357>, @jhuber6 wrote:

> In D156816#4551338 <https://reviews.llvm.org/D156816#4551338>, @yaxunl wrote:
>
>>> FFI isn't the reason you'd use these, it's for generic access to the actual backend. E.g. an `addrspace(3)` global is local memory, if it's external it's dynamic. Having these named is better than doing it via the numerical address space. I'd like to use these in the C++ / OpenMP codes instead of the numeric ones but I don't like needing to use `opencl` in the name. Similarly to how we have the OpenCL atomics that should be usable outside of OpenCL.
>>
>> I agree these attributes are useful in other languages, but "global" and "local" may need a more generic name suitable for all offloading languages. To me, "device" can be a good alternative to "global". even "shared" seems clearer than "local".
>
> Global is common in https://llvm.org/docs/AMDGPUUsage.html#address-spaces and https://llvm.org/docs/NVPTXUsage.html#address-spaces. The main problem is `local` vs `shared` and `private` vs `local`. Unsure which one we should prefer in this case. Generally I feel a lot of this OpenCL stuff should've been named commonly at the start considering you can use most of them outside of the actual OpenCL language just fine.

Why not to just use target address space and define it to some macro with desirable spelling?

I don't think renaming OpenCL address space to something else makes sense. It might make more sense to just introduced different model of address spaces completely. But if you use OpenCL ones then it makes sense to have adequate naming so its documentation and etc can be located.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816