[PATCH] D77777: [nvptx] Add `nvvm.texsurf.handle` internalizer.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D77777#1975406 <https://reviews.llvm.org/D77777#1975406>, @tra wrote:

> In D77777#1975178 <https://reviews.llvm.org/D77777#1975178>, @hliao wrote:
>
> > the 1st argument in `llvm.nvvm.texsurf.hande.internal` or the 2nd one in `llvm.nvvm.texsurf.handle` must be kept as an immediate or constant value, i.e. that global variable. However, optimizations will find common code in the following
> >
> >   if (cond) {
> >     %hnd = texsurf.handle.internal(@tex1);
> >   } else {
> >     %hnd = texsurf.handle.internal(@tex2)
> >   }
> >   = use(%hnd)
> >
> >
> > and hoist or sink it into
> >
> >   if (cond) {
> >     %ptr = @tex1;
> >   } else {
> >     %ptr = @tex2;
> >   }
> >   %hnd = texsurf.handle.intenal(%ptr);
> >   = use(%hnd)
> >
> >
> > The backend cannot handle non immediate operand in `texsurf.handle`. The similar thing happens to `read.register` as well as it also assumes its argument is always an immediate value.
>
>
> I wonder if we can use `token` types to represent the handle? https://reviews.llvm.org/D11861
>  @majnemer -- would this use case be suitable for the `token` type?


If we still could make PHI over token, it canont serve this purpose. Check `llvm::canReplaceOperandWithVariable` for operand for details.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77777/new/

https://reviews.llvm.org/D77777