[clang] [llvm] [mlir] [NVPTX] Add support for Shared Cluster Memory address space. (PR #135444)

Artem Belevich via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 15 16:26:45 PDT 2025


================
@@ -982,8 +982,9 @@ void NVPTXDAGToDAGISel::SelectAddrSpaceCast(SDNode *N) {
     case ADDRESS_SPACE_SHARED:
       Opc = TM.is64Bit() ? NVPTX::cvta_shared_64 : NVPTX::cvta_shared;
       break;
-    case ADDRESS_SPACE_DSHARED:
-      Opc = TM.is64Bit() ? NVPTX::cvta_dshared_64 : NVPTX::cvta_dshared;
+    case ADDRESS_SPACE_SHARED_CLUSTER:
+      Opc = TM.is64Bit() ? NVPTX::cvta_shared_cluster_64
+                         : NVPTX::cvta_shared_cluster;
----------------
Artem-B wrote:

> What matters for cvta is the size of the generic pointers, which I think is always 64, right?

It will depend on the compilation mode. You are correct that we can not produce valid code for shared_cluster conversions in 32-bit mode, so the question is -- how are we going to fail?

If we unconditionally use `NVPTX::cvta_shared_cluster_64` we'll likely break other things because it will hardcode the assumption that generic pointer is 64-bit, while the rest of the DAG and the lowering machinery would be expecting it to be 32 bits. I suspect we'll run into an assertion somewhere. The bottom line is that we may still want to go through the motions, and pretend that we can convert AS to/from cluster_shared in 32-bit mode , so we can finish the compilation, and *then* let ptxas report an error. At least at that point the user would be able to examine the PTX and reason about what went wrong. 

https://github.com/llvm/llvm-project/pull/135444


More information about the llvm-commits mailing list