Anastasia added a comment. In D124382#3496417 <https://reviews.llvm.org/D124382#3496417>, @jchlanda wrote:
> In D124382#3480600 <https://reviews.llvm.org/D124382#3480600>, @Anastasia > wrote: > >> > > > >> And I think we could add this feature in a very light way for example by >> reserving the numbers from the clang `LangAS` enum to be used with the >> language address spaces in the prototypes of builtins. > > I'm not sure I understand how that would look, could you please elaborate? We could reserve the IDs from LangAS enums to be used in https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Builtins.def#L65, but we could also extend the syntax more naturally i.e. numbers could be used for target address spaces and we could add some letter based syntax for language address spaces. >> Just to understand further - do you need the builtins to have a specific >> address space prototype? And do you need this to improve error handling in >> libclc code base? > > With the wrappers suggested we could declare all the pointers to be in > generic AS and that would get us around the target vs language AS problem. I > don't think that would improve the situation, as from llvm perspective/use > case all those builtins would be incorrect and there would be no way for > users to tell that there is a specific AS requirement on them, nor would the > compiler be able to warn/error. Then the only thing making it work would be > those wrappers, embedded deeply in the source of libclc, which at the moment > is not even shipped with upstream llvm. > The builtins in question are not exclusively OpenCL/SYCL related, say > `TARGET_BUILTIN(__nvvm_cp_async_ca_shared_global_16, "vv*3vC*1", "", > AND(SM_80,PTX70))` would need to take both pointer in a generic address space > here. It feels like explicitly providing AS in the prototype is needed. My understanding was that Clang low level builtins are not desirable for uses in the application code directly. They are more targeted at tooling developers and low level libraries uses. Which is why this problem has been worked around by declaring the wrapper overload with correct address spaces in the tooling projects. My understanding was that you need those builtins in the libclc code? >> this for example won’t work for builtins that are shared between targets. > > While I agree in principle, I'm not sure if there are any target agnostic and > AS specific builtins, sounds like a dangerous thing to introduce. And in any > case, it's the target that provides the AS map. In OpenCL we actually have quite some target agnostic builtins. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124382/new/ https://reviews.llvm.org/D124382 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
