[llvm] [SPIRV] Implement handle_fromBinding intrinsic. (PR #111052)

[Vyacheslav Levytskyy via llvm-commits]

================
@@ -713,6 +713,29 @@ Register SPIRVGlobalRegistry::buildGlobalVariable(
   return Reg;
 }
 
+Register SPIRVGlobalRegistry::getOrCreateGlobalVariableWithBinding(
+    const SPIRVType *VarType, uint32_t Set, uint32_t Binding,
+    MachineIRBuilder &MIRBuilder) {
+  SPIRVType *VarPointerTypeReg = getOrCreateSPIRVPointerType(
+      VarType, MIRBuilder, SPIRV::StorageClass::UniformConstant);
+  Register VarReg =
+      MIRBuilder.getMRI()->createVirtualRegister(&SPIRV::iIDRegClass);
+
+  // TODO: The name should come from the llvm-ir, but how that name will be
+  // passed from the HLSL to the backend has not been decided. Using this place
+  // holder for now. We use the result register of the type in the name.
+  std::string name = ("__resource_" + Twine(VarType->getOperand(0).getReg()) +
----------------
VyacheslavLevytskyy wrote:

I'm not too sure about merits of using the register as a part of the name. The point is that this register is a number that may be and will be reused in the next function. It's locally unique in the current machine function, but it's not unique globally, because instruction selection is happening before we allocate final register numbers for the SPIRV output. I'm not 100% sure, but probably when you modify your test case so, that you have the second function with absolutely the same content as the only function you have now, you will get a name collision between those two functions, because I'm pretty sure that `VarType->getOperand(0).getReg()` will have the same value in both functions. Just as an idea, may be we should see this second function in the test case as a check and proof of valid/unique global var names generation.

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