[Mlir-commits] [mlir] [MLIR][XeVM] Rewrite llvm.alloca if addr_space is not 0 (PR #183417)

[Artem Kroviakov]

================
@@ -836,6 +838,46 @@ class SubgroupOpWorkitemOpToOCLPattern : public OpConversionPattern<OpType> {
   }
 };
 
+static unsigned getNextGlobalIdx() {
+  static unsigned globalIdx = 0;
+  return globalIdx++;
+}
+
+class AllocaToGlobalPattern : public OpConversionPattern<LLVM::AllocaOp> {
+  using OpConversionPattern::OpConversionPattern;
+  LogicalResult
+  matchAndRewrite(LLVM::AllocaOp op, LLVM::AllocaOp::Adaptor adaptor,
+                  ConversionPatternRewriter &rewriter) const override {
+    auto moduleOp = op->getParentOfType<ModuleOp>();
+    if (!moduleOp)
+      return failure();
+    auto ptrType = cast<LLVM::LLVMPointerType>(op.getType());
+    auto addrSpace = ptrType.getAddressSpace();
+    if (addrSpace != 3)
----------------
akroviakov wrote:

> actual numeric value differs for Vulkan and OpenCL.


Right now, xevm effectively `constexpr` maps to opencl only, we have `constexpr spirv::ClientAPI clientAPI = spirv::ClientAPI::OpenCL;` inside the memory space conversion in `GPUToLLVMSPV`. The memory space mapping is both independent of xevm's address spaces and goes straight to numeric values. 


Assuming we support multiple backends (with different address space mappings), the target attribute would be _required_ either at the `GPUToXeVM` level or during the translation for mapping to target numerics.

For now, this temporary solution is functionally fine, but it does not look well. We have independent mapping in gputollvmspv, xevm enums and hardcoded values, all in the same "below gpu dialect" xevm stack. 

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