[llvm] [RFC][AMDGPU][InsertWaitCnt] Move WaitEventType into separate HWEvent header (PR #202886)

[Pierre van Houtryve via llvm-commits]

================
@@ -0,0 +1,120 @@
+//===- AMDGPUHWEvents.h -----------------------------------------*- C++ -*-===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_LIB_TARGET_AMDGPU_UTILS_AMDGPUHWEVENTS_H
+#define LLVM_LIB_TARGET_AMDGPU_UTILS_AMDGPUHWEVENTS_H
+
+#include "llvm/ADT/Sequence.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace llvm {
+class raw_ostream;
+
+namespace AMDGPU {
+
+enum class HWEvent : unsigned char {
+#define AMDGPU_HW_EVENT(X) X,
+#define AMDGPU_FIRST_HW_EVENT(X) FIRST_WAIT_EVENT = X,
+#define AMDGPU_LAST_HW_EVENT(X) NUM_WAIT_EVENTS = X,
+#include "AMDGPUHWEvents.def"
+};
+
+} // namespace AMDGPU
+
+template <> struct enum_iteration_traits<AMDGPU::HWEvent> {
+  static constexpr bool is_iterable = true; // NOLINT
+};
+
+namespace AMDGPU {
+
+static constexpr StringLiteral toString(HWEvent Event) {
+  switch (Event) {
+#define AMDGPU_HW_EVENT(EVENT)                                                 \
+  case HWEvent::EVENT:                                                         \
+    return #EVENT;
+#include "AMDGPUHWEvents.def"
+  }
+
+  return "";
+}
+
+/// Return an iterator over all events between FIRST_WAIT_EVENT
+/// and \c MaxEvent (exclusive, default value yields an enumeration over
+/// all counters).
+// NOLINTNEXTLINE
+inline iota_range<HWEvent>
+hw_events(HWEvent MaxEvent = HWEvent::NUM_WAIT_EVENTS) {
+  return enum_seq(HWEvent::FIRST_WAIT_EVENT, MaxEvent);
+}
+
+class HWEventSet {
----------------
Pierre-vh wrote:

> That's what it's for?
Ah right, it says we can do it. I thought it was something you'd need to use in .cpp file and not in headers.

In any case, if I am to use it, I need to refactor the enum so it's a bitmask, which probably means manually defining all entries as well because they all need to be defined as `1 << N` instead of `= N`.

I'm okay with doing this, but can I suggest doing it as a follow-up patch ? I'll look at adding a patch in the stack do to this. I intended this patch to be a simple move + rename but it's turning quickly into a redesign of the enum. 

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