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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
