[llvm] Reland [AMDGPU] Add AMDGPU specific variadic operation MCExprs (PR #84562)

[Janek van Oirschot via llvm-commits]

================
@@ -0,0 +1,103 @@
+//===- AMDGPUMCExpr.cpp - AMDGPU specific MC expression classes -----------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "AMDGPUMCExpr.h"
+#include "llvm/MC/MCContext.h"
+#include "llvm/MC/MCStreamer.h"
+#include "llvm/MC/MCSymbol.h"
+#include "llvm/MC/MCValue.h"
+#include "llvm/Support/Allocator.h"
+#include "llvm/Support/raw_ostream.h"
+#include <optional>
+
+using namespace llvm;
+
+const AMDGPUVariadicMCExpr *
+AMDGPUVariadicMCExpr::create(VariadicKind Kind, ArrayRef<const MCExpr *> Args,
+                             MCContext &Ctx) {
+  // Storage for the argument's 'const MCExpr*' allocated through MCContext new
+  // placement which means that AMDGPUVariadicMCExpr objects and all of its
+  // contents will now be allocated through MCContext new placement.
+  //
+  // Will result in an asan failure if allocated on the heap (e.g., through
+  // SmallVector's grow).
+  const MCExpr **CtxArgs = static_cast<const MCExpr **>(
+      Ctx.allocate(sizeof(const MCExpr *) * Args.size()));
+  std::uninitialized_copy(Args.begin(), Args.end(), CtxArgs);
----------------
JanekvO wrote:

> The regular non-target MCExpr's all have an MCContext argument
I believe it's only their `create` functions that have it but it is not forwarded beyond that (i.e., to the MCExpr constructor).

> It's not clear to me exactly what that comment means by "trivial"
I assume it's referring to the C++ standard definition of trivial destructors but I don't believe the MCTargetExpr class itself has a trivial destructor according to those rules.

I'm okay with going off-script with the AMDGPUVariadicMCExpr and adding the MCContext as member + user defined destructor, it doesn't trigger the asan leak either way.

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