[llvm] [Offload] Implement the remaining initial Offload API (PR #122106)

[Piotr Balcer via llvm-commits]

================
@@ -0,0 +1,48 @@
+//===-- Memory.td - Memory definitions for Offload ---------*- tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file contains Offload API definitions related to memory allocations
+//
+//===----------------------------------------------------------------------===//
+
+def : Enum {
+  let name = "ol_alloc_type_t";
+  let desc = "Represents the type of allocation made with olMemAlloc.";
+  let etors = [
+    Etor<"HOST", "Host allocation">,
+    Etor<"DEVICE", "Device allocation">,
+    Etor<"SHARED", "Shared allocation">
+  ];
+}
+
+def : Function {
+  let name = "olMemAlloc";
+  let desc = "Creates a memory allocation on the specified device.";
+  let params = [
+    Param<"ol_device_handle_t", "Device", "handle of the device to allocate on", PARAM_IN>,
+    Param<"ol_alloc_type_t", "Type", "type of the allocation", PARAM_IN>,
+    Param<"size_t", "Size", "size of the allocation in bytes", PARAM_IN>,
+    Param<"void**", "AllocationOut", "output for the allocated pointer", PARAM_OUT>
+  ];
+  let returns = [
+    Return<"OL_ERRC_INVALID_SIZE", [
+      "`Size == 0`"
+    ]>
+  ];
+}
+
+def : Function {
+  let name = "olMemFree";
+  let desc = "Frees a memory allocation previously made by olMemAlloc.";
+  let params = [
+    Param<"ol_device_handle_t", "Device", "handle of the device to allocate on", PARAM_IN>,
----------------
pbalcer wrote:

> There's maybe a better way for the plugins to manage it themselves but this seems like an ok first step.

But, without any sort of handle in the free function, you won't know how to dispatch the call to a plugin. In UR, every function has a handle pointer precisely so that it's always possible to route the call to the appropriate underlying adapter/plugin function.

To me this looks like we are trading-off performance and memory (maintaining a DenseMap of **all** allocations won't be cheap and will likely require a mutex) against... convenience of using this API in SYCL/OpenMP implementations?

I don't think that's the right trade-off. If using a device here would be complicated, maybe we should require a platform handle?
The abstraction used across SYCL, OpenCL and Intel Level Zero for this purpose is context.

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