[llvm] [Offload] Add Error Codes to PluginInterface (PR #138258)

[Ross Brunton via llvm-commits]

================
@@ -83,26 +83,30 @@ def : Typedef {
   let value = "void *";
 }
 
-def : Enum {
+def ErrorCode : Enum {
   let name = "ol_errc_t";
   let desc = "Defines Return/Error codes";
   let etors =[
-    Etor<"SUCCESS", "Success">,
-    Etor<"INVALID_VALUE", "Invalid Value">,
+    Etor<"SUCCESS", "Success", 0>,
+
+    // Universal errors
+    Etor<"INVALID_NULL_POINTER", "A pointer argument is null when it should not be">,
+    Etor<"INVALID_ARGUMENT", "An argument is invalid">,
+    Etor<"OUT_OF_RESOURCES", "Out of resources">,
+    Etor<"UNSUPPORTED", "generic error code for unsupported features and enums">,
+
+    // Liboffload specific errors
+    Etor<"INVALID_VALUE", "Invalid Value", 0x1000>,
     Etor<"INVALID_PLATFORM", "Invalid platform">,
     Etor<"INVALID_DEVICE", "Invalid device">,
     Etor<"INVALID_QUEUE", "Invalid queue">,
     Etor<"INVALID_EVENT", "Invalid event">,
     Etor<"INVALID_KERNEL_NAME", "Named kernel not found in the program binary">,
-    Etor<"OUT_OF_RESOURCES", "Out of resources">,
-    Etor<"UNSUPPORTED_FEATURE", "generic error code for unsupported features">,
-    Etor<"INVALID_ARGUMENT", "generic error code for invalid arguments">,
     Etor<"INVALID_NULL_HANDLE", "handle argument is not valid">,
-    Etor<"INVALID_NULL_POINTER", "pointer argument may not be nullptr">,
     Etor<"INVALID_SIZE", "invalid size or dimensions (e.g., must not be zero, or is out of bounds)">,
     Etor<"INVALID_ENUMERATION", "enumerator argument is not valid">,
-    Etor<"UNSUPPORTED_ENUMERATION", "enumerator argument is not supported by the device">,
-    Etor<"UNKNOWN", "Unknown or internal error">
+
+    Etor<"UNKNOWN", "Unknown or internal error", 0x10000>
----------------
RossBrunton wrote:

My understanding was that it was desirable to give backends the ability to pass backend-specific error codes to PluginInterface users. If that is not the case, I'm perfectly happy to axe the categories thing and have them all be in the same pool.

Thinking out loud here, maybe having a field for the `CUResult`/`hsa_status_t` in the `ol_result_t` struct might be a better solution to this? But that's a future discussion.

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