[llvm] Don't rely on undefined behavior to store how a `User` object's allocation is laid out (PR #105714)

[Reid Kleckner via llvm-commits]

================
@@ -43,39 +43,80 @@ struct OperandTraits;
 
 class User : public Value {
   friend struct HungoffOperandTraits;
+  template <class ConstantClass> friend struct ConstantAggrKeyType;
 
   LLVM_ATTRIBUTE_ALWAYS_INLINE static void *
   allocateFixedOperandUser(size_t, unsigned, unsigned);
 
 protected:
+  // Disable the default operator new, as all subclasses must use one of the
+  // custom operators below depending on how they store their operands.
+  void *operator new(size_t Size) = delete;
+
+  /// Information about how a User object was allocated, to be passed into the
+  /// User constructor.
+  ///
+  /// DO NOT USE DIRECTLY. Use one of the `AllocMarker` structs instead.
----------------
rnk wrote:

Is it feasible to enforce this guidance to avoid direct use through explicit private constructors and friend class declarations, or is that too difficult? It seems like it might not be worth it, you'd have to make the constructors private, then friend the marker classes, and then maybe explicitly default the copy constructor and make it public, so it can be freely passed around.

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