[llvm] [SPIR-V] Add InferAddrSpaces pass to the backend (PR #137766)

Victor Lomuller via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 30 03:11:44 PDT 2025


Nathan =?utf-8?q?Gauër?= <brioche at google.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/137766 at github.com>


================
@@ -190,6 +191,14 @@ void SPIRVPassConfig::addIRPasses() {
   TargetPassConfig::addIRPasses();
 
   if (TM.getSubtargetImpl()->isVulkanEnv()) {
+    // The frontend has a tendency to quickly addrspacecast pointers to the
+    // default address space, and relies on addrspacecast instructions at the
+    // boundaries. Vulkan does not allow such things, and we must keep the
+    // pointer address space stable.
+    // This pass will determine real address space of a pointer, and patch
+    // instructions removing Addrspacecasts.
+    addPass(createInferAddressSpacesPass(/* AddressSpace= */ 0));
----------------
Naghasan wrote:

> In the logical SPIRV world (outside of buffer content), there are no relationships between addresses like a flat address space would give, pointers are abstract and have no numerical value.

I know SPIR-V ;)

My point is not about SPIR-V, but about the LLVM representation you have for this target. I haven't checked, but I suspect you get these addrspacecast because `LangAS::Default` maps to 0. So, 0 is defacto used as your (unwanted) flat address space and you use the infer pass to workaround it. I agree `0 is flat` isn't right from a SPIR-V perspective, although I think it is for the LLVM representation you use.

I'm suggesting this because it makes sense for the backend in general to have this hook implemented (and the infer pass enabled in general as well, but I don't think it should be enabled with this patch).

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


More information about the llvm-commits mailing list