[llvm] [Offload] Introduce offload-tblgen and initial new API implementation (PR #108413)

[Callum Fare via llvm-commits]

================
@@ -0,0 +1,75 @@
+def : Macro {
+  let name = "OFFLOAD_APICALL";
+  let desc = "Calling convention for all API functions";
+  let condition = "defined(_WIN32)";
+  let value = "__cdecl";
+  let alt_value = "";
+}
+
+def : Macro {
+  let name = "OFFLOAD_APIEXPORT";
+  let desc = "Microsoft-specific dllexport storage-class attribute";
+  let condition = "defined(_WIN32)";
+  let value = "__declspec(dllexport)";
+  let alt_value = "";
+}
+
+def : Macro {
+  let name = "OFFLOAD_DLLEXPORT";
+  let desc = "Microsoft-specific dllexport storage-class attribute";
+  let condition = "defined(_WIN32)";
+  let value = "__declspec(dllexport)";
+}
+
+def : Macro {
+  let name = "OFFLOAD_DLLEXPORT";
+  let desc = "GCC-specific dllexport storage-class attribute";
+  let condition = "__GNUC__ >= 4";
+  let value = "__attribute__ ((visibility (\"default\")))";
+  let alt_value = "";
+}
+
+def : Typedef {
+  let name = "offload_bool_t";
+  let value = "uint8_t";
+  let desc = "compiler-independent type";
+}
+
+def : Handle {
+  let name = "offload_platform_handle_t";
+  let desc = "Handle of a platform instance";
+}
+
+def : Handle {
+  let name = "offload_device_handle_t";
+  let desc = "Handle of platform's device object";
+}
+
+def : Handle {
+  let name = "offload_context_handle_t";
+  let desc = "Handle of context object";
+}
+
+def : Enum {
+  let name = "offload_result_t";
----------------
callumfare wrote:

This is definitely possible, but I have some concerns about that being the default path for returning errors. 

With SYCL we programmatically deal with error codes, converting them to appropriate SYCL exceptions etc. See [here](https://github.com/intel/llvm/blob/c22d238c417974e540beebf2c5bd6512e32926f6/sycl/source/detail/error_handling/error_handling.cpp#L353) for an example. Having errors just be strings makes this more difficult to handle, and liable to be unintentionally broken.

Could we have a specific error condition (e.g. `RESULT_ERROR_CUSTOM`) that represents a custom error state that can then be queried with a function like `offloadGetLastCustomError`? We have something similar in UR (`UR_RESULT_ERROR_ADAPTER_SPECIFIC`). Rather than using an index into a table of strings, we have a thread_local buffer for a single error message, and it's the caller's responsibility to query the contents of it after the failing API call (subsequent calls may overwrite it). This design avoids complications with the lifetime of the error strings.

Another possibility is some kind of logging callback where Offload can write out additional error/debug information for the language runtime to handle in whatever way is suitable. That would allow an enum to be used as the normal return code, while additional more descriptive information is optionally available.


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