[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