[llvm] [CodeGen][ARM64EC] Add support for hybrid_patchable attribute. (PR #92965)

[Eli Friedman via llvm-commits]

================
@@ -670,10 +746,40 @@ bool AArch64Arm64ECCallLowering::runOnModule(Module &Mod) {
 
   GuardFnType = FunctionType::get(PtrTy, {PtrTy, PtrTy}, false);
   GuardFnPtrType = PointerType::get(GuardFnType, 0);
+  DispatchFnType = FunctionType::get(PtrTy, {PtrTy, PtrTy, PtrTy}, false);
+  DispatchFnPtrType = PointerType::get(DispatchFnType, 0);
   GuardFnCFGlobal =
       M->getOrInsertGlobal("__os_arm64x_check_icall_cfg", GuardFnPtrType);
   GuardFnGlobal =
       M->getOrInsertGlobal("__os_arm64x_check_icall", GuardFnPtrType);
+  DispatchFnGlobal =
+      M->getOrInsertGlobal("__os_arm64x_dispatch_call", DispatchFnPtrType);
+
+  // Rename hybrid patchable functions and change callers to use an external
+  // linkage function call instead.
+  SetVector<Function *> PatchableFns;
+  for (Function &F : Mod) {
+    if (!F.hasFnAttribute(Attribute::HybridPatchable) ||
+        F.getName().ends_with("$hp_target"))
+      continue;
+
+    if (F.isDeclaration() || F.hasLocalLinkage()) {
+      F.removeFnAttr(Attribute::HybridPatchable);
+      continue;
+    }
+
+    if (std::optional<std::string> MangledName =
+            getArm64ECMangledFunctionName(F.getName().str())) {
+      std::string OrigName(F.getName());
+      F.setName(MangledName.value() + "$hp_target");
+
+      Function *EF = Function::Create(
----------------
efriedma-quic wrote:

The current version seems okay.  The whole EXP+ thing would require a significant IR extension to properly represent, which doesn't seem worth it.  (We could theoretically define a Constant specifically to refer to the linker-generated hybrid_patchable thunk of a function, and allow aliases to refer to such a constant, but that seems like overkill if it would only be used in this one place.)

Maybe worth adding a comment in the code describing the intentional gap between a normal alias and what we're emitting here.

Not sure about anti-dep aliases; I still haven't quite wrapped my head around the semantics of antidep.  I guess from the compiler's perspective, it might be close enough to a weak alias that we could just get away with setting the linkage to "weak", and adding some metadata to mark it as anti-dep?

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