[PATCH] D114367: [NVPTX] Auto-generate tests for sufrace and texture instructions

[Artem Belevich via Phabricator via llvm-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.


================
Comment at: llvm/test/CodeGen/NVPTX/surf-tex.py:190-192
+  # With 'cuda' environment surface is copied with ld.param, so the
+  # instruction uses a register. For 'nvcl' the instruction uses the
+  # parameter directly.
----------------
asavonic wrote:
> tra wrote:
> > Interesting. PTX spec is a bit vague about what's OK and not OK to do with function parameters. We do know that `ld.param` is the only way to read them. Taking address forces creation of a local copy. I wonder what surface lookup with direct use of parameter does under the hood -- treats it as a taken address and forces a local copy, too?
> PTX spec s5.3 "Texture Sampler and Surface Types" summarizes how surface/texture variables can be used, but does not include a lot of details on how they actually work.
> ```
> Variable definition within global (module) scope and in kernel entry parameter lists. 
> ```
> It does not say this explicitly, but I *guess* that `.surfref` as a kernel parameter works the same as a global `.surfref` and therefore can be used directly.
> ```
> Creating pointers to opaque variables using mov, e.g., mov.u64 reg, opaque_var;. The resulting pointer may be stored to and loaded from memory, passed as a parameter to functions, and de-referenced by texture and surface load, store, and query instructions, but the pointer cannot otherwise be treated as an address, i.e., accessing the pointer with ld and st instructions, or performing pointer arithmetic will result in undefined results. 
> ```
> However, when we take a "pointer" to a surface/texture as a register, it now works like any other type and needs an `ld.param` if it is passed to a function.
> but the pointer cannot otherwise be treated as an address

Ugh. This part of PTX spec is such a pain. Adding special texture/surface reference magic to it does not help at all. :-(

We may need to add a special case for the references to the nvptx-lower-args pass. We currently allow some byval parameters to be accessed directly, but it does not know anything about textures/surfaces.


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

https://reviews.llvm.org/D114367