hliao added a comment. In D76365#1932517 <https://reviews.llvm.org/D76365#1932517>, @tra wrote:
> In D76365#1932439 <https://reviews.llvm.org/D76365#1932439>, @hliao wrote: > > > > > > > > > That's a magic. I could not figure out how it works. From its use, e.g. > > `tex2D` on `texture<T, cudaTextureType2D, cudaReadModeElementType>`, > > > > __nv_tex_surf_handler("__tex2D_v2", (typename > > __nv_tex_rmet_cast<T>::type) &temp, t, x, y); > > > > > > `__tex2D_v2` is a string literal. However, it's more likely a underly > > function name for the real implementation. Hardly imagine that that string > > literal is checked directly instead used for constructing the real function > > name. If that's the case, we also need to find that where that underlying > > functions are defined as the device bitcode library has no such definition. > > Most likely it's a compiler built-in with no implementation we could reuse > and we'll need to implement our own. It should be fairly straightforward to > figure out what it does by compiling all variants used by CUDA headers and > observing generated PTX. The first 'meta' argument may be tricky, but we > should be able to retrieve the constant string value in the front-end and map > it to appropriate intrinsic or generate necessary glue. I could add that support gradually in my spare time. The goal of this patch not only addresses the texture/surface reference support for CUDA but also for HIP to keep the maximum compatibility. Once this is landed, we will follow the similar approach in HIP. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76365/new/ https://reviews.llvm.org/D76365 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
