tra added a comment.
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.
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
