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

[Nathan Gauër via llvm-commits]

================
@@ -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));
----------------
Keenuts wrote:

Thanks for the info. I'm quite fuzzy on this, so let me know If I'm missing something:

In our case yes, we map to 0 -> SPIRV::Function, but it is true other targets map this to other values (Sycl says DefaultAS is 4 for ex, which is converted to SPIRV::Generic).

But there is something I don't understand: It feels like this pass is using `getFlatAddressSpace()` to get the AS Clang would generally addrspacecast eagerly to, and possibly keep other valid ones. But I don't get why the AS being 'flat' is important for this specific pass.

Hence why I'm not eager to add the `getFlatAddressSpace()` in the target, because I feel the name implies something more than just `this is the default AS`.

Putting this aside, the LangAS -> int mapping is done in the FE, so I don't think we should be doing a `isSycl()` kind of check to pick what the default AS translates to.
In that regards, it is indeed weird to put `addressSpace = 0` as if that was always the case, but wouldn't any other condition we put as-arbitrary?



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