[Clang][AArch64] Define __USER_LABEL_PREFIX__ to # for ARM64EC

[bylaws]

This is required so that the linker knows that any symbols defined in assembly code are ARM64EC rather than X86_64.

CC: @cjacek

[llvmbot]

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-backend-aarch64

Author: Billy Laws (bylaws)

Changes

This is required so that the linker knows that any symbols defined in assembly code are ARM64EC rather than X86_64.

CC: @cjacek

---

Full diff: https://github.com/llvm/llvm-project/pull/78913.diff

1 Files Affected:

• (modified) clang/lib/Basic/Targets/AArch64.cpp (+6-4)

diff --git a/clang/lib/Basic/Targets/AArch64.cpp b/clang/lib/Basic/Targets/AArch64.cpp
index d47181bfca4fc86..4f57c30279a91fb 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -1462,10 +1462,12 @@ WindowsARM64TargetInfo::WindowsARM64TargetInfo(const llvm::Triple &Triple,
 }
 
 void WindowsARM64TargetInfo::setDataLayout() {
-  resetDataLayout(Triple.isOSBinFormatMachO()
-                      ? "e-m:o-i64:64-i128:128-n32:64-S128"
-                      : "e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128",
-                  Triple.isOSBinFormatMachO() ? "_" : "");
+  if (Triple.isOSBinFormatMachO()) {
+    resetDataLayout("e-m:o-i64:64-i128:128-n32:64-S128", "_");
+  } else {
+    resetDataLayout("e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128",
+                    Triple.isWindowsArm64EC() ? "#" : "");
+  }
 }
 
 TargetInfo::BuiltinVaListKind

[jroelofs]

Weird, I wonder when Windows+AArch64+Mach-O is ever used... maybe @compnerd knows?

[mstorsjo]

AFAIK Windows+MachO is used in some cases for JIT scenarios, because the runtime linking support in the JIT is much more complete for MachO than it is for PE/COFF.

[cjacek]

Note that this prefix is expected on ARM64EC only for C function symbols. C++ symbols use a different mangling and data symbols are not decorated at all. This is different from other cases when __USER_LABEL_PREFIX__ is defined, I'm not sure.

[efriedma-quic]

I can sort of see how a define could be useful, but this doesn't match any existing usage of USER_LABEL_PREFIX given the relevant rules. I think reusing the name is more likely to cause confusion, rather than help anyone.

[bylaws]

@efriedma-quic Fair enough, I found this cleaned up things on the compiler-rt side but even then it still needed changes to handle concatenating a #, and I'd imagine that to be the same for any other existing user. It would still be nice to have something equivalent to A64NAME for user code but that probably better fits in mingw.