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

Reply via email to