[llvm] [SYCL] Add platform enumeration and info query using liboffload (PR #166927)

[Andrei Elovikov via llvm-commits]

================
@@ -0,0 +1,116 @@
+//===----------------------------------------------------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+///
+/// \file
+/// This file contains the declaration of the SYCL 2020 Exception class
+/// interface (4.13.2.)
+///
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBSYCL___IMPL_EXCEPTION_HPP
+#define _LIBSYCL___IMPL_EXCEPTION_HPP
+
+#include <sycl/__impl/detail/config.hpp>
+
+#include <exception>
+#include <memory>
+#include <string>
+#include <system_error>
+#include <type_traits>
+#include <vector>
+
+_LIBSYCL_BEGIN_NAMESPACE_SYCL
+
+class context;
+
+enum class errc : int {
+  success = 0,
+  runtime = 1,
+  kernel = 2,
+  accessor = 3,
+  nd_range = 4,
+  event = 5,
+  kernel_argument = 6,
+  build = 7,
+  invalid = 8,
+  memory_allocation = 9,
+  platform = 10,
+  profiling = 11,
+  feature_not_supported = 12,
+  kernel_not_supported = 13,
+  backend_mismatch = 14,
+};
+
+/// Constructs an error code using E and sycl_category()
+_LIBSYCL_EXPORT std::error_code make_error_code(sycl::errc E) noexcept;
+
+/// Obtains a reference to the static error category object for SYCL errors.
+_LIBSYCL_EXPORT const std::error_category &sycl_category() noexcept;
+
+// Derive from std::exception so uncaught exceptions are printed in c++ default
+// exception handler.
+// Virtual inheritance is mandated by SYCL 2020.
+// 4.13.2. Exception class interface
+class _LIBSYCL_EXPORT exception : public virtual std::exception {
+public:
+  exception(std::error_code, const char *);
+  exception(std::error_code Ec, const std::string &Msg)
+      : exception(Ec, Msg.c_str()) {}
+
+  exception(std::error_code EC) : exception(EC, "") {}
+  exception(int EV, const std::error_category &ECat, const std::string &WhatArg)
+      : exception(EV, ECat, WhatArg.c_str()) {}
+  exception(int EV, const std::error_category &ECat, const char *WhatArg)
+      : exception({EV, ECat}, WhatArg) {}
+  exception(int EV, const std::error_category &ECat)
+      : exception({EV, ECat}, "") {}
+
+  virtual ~exception();
+
+  const std::error_code &code() const noexcept;
+  const std::error_category &category() const noexcept;
+
+  const char *what() const noexcept final;
+
+  bool has_context() const noexcept;
+
+private:
+  // Exceptions must be noexcept copy constructible, so cannot use std::string
+  // directly.
+  std::shared_ptr<std::string> MMessage;
----------------
aelovikov-intel wrote:

This is a great opportunity to start conversation with libcxx developers (@ldionne to start that, I think) on how/if we can share some of their implementation details. `__libcpp_refstring` would be perfect here.

Another potential opportunity (in a not so distant future PR) would be related to the implementation of `std::shared_ptr`. In a nutshell, some of the SYCL objects would probably be implemented (simplified) like this:

```c++
class event_impl; // defined inside libsycl.so, not exposed to the public headers
class event {
public:
  /* ... */
private:
  std::shared_ptr<event_impl> pImpl;
};
```

Ideally, we'd want to inherit `event_impl` from `std::enable_shared_from_this`. The problem we saw is that inheritance by itself slowed down construction of `event_impl` because even if know that we always create them via `make_shared<event_iml>` the implementation still had to initialize the `std::enable_shared_from_this` subobject with atomic operations resulting in a measurable overhead. If we could somehow use most the libc++'s implementation of these but with a way to communicate extra guarantees of how those objects are created and not to pay the price of these initialization atomics, that would be great, but I'm not sure if that's possible/worth maintenance efforts.

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