[LLD][COFF] Support ARM64EC in BitcodeFile::getMachineType

[cjacek]

No description provided.

[llvmbot]

@llvm/pr-subscribers-platform-windows

@llvm/pr-subscribers-lld-coff

Author: Jacek Caban (cjacek)

Changes

---

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

4 Files Affected:

• (modified) lld/COFF/InputFiles.cpp (+3-2)
• (modified) lld/test/COFF/Inputs/loadconfig-arm64ec.s (+1)
• (modified) lld/test/COFF/arm64ec-pdb.test (+7-5)
• (added) lld/test/COFF/lto-arm64ec.ll (+29)

diff --git a/lld/COFF/InputFiles.cpp b/lld/COFF/InputFiles.cpp
index 4b2d6e511df1a1..6b5efb34b3f3e7 100644
--- a/lld/COFF/InputFiles.cpp
+++ b/lld/COFF/InputFiles.cpp
@@ -1279,7 +1279,8 @@ void BitcodeFile::parseLazy() {
 }
 
 MachineTypes BitcodeFile::getMachineType() const {
-  switch (Triple(obj->getTargetTriple()).getArch()) {
+  Triple t(obj->getTargetTriple());
+  switch (t.getArch()) {
   case Triple::x86_64:
     return AMD64;
   case Triple::x86:
@@ -1288,7 +1289,7 @@ MachineTypes BitcodeFile::getMachineType() const {
   case Triple::thumb:
     return ARMNT;
   case Triple::aarch64:
-    return ARM64;
+    return t.isWindowsArm64EC() ? ARM64EC : ARM64;
   default:
     return IMAGE_FILE_MACHINE_UNKNOWN;
   }
diff --git a/lld/test/COFF/Inputs/loadconfig-arm64ec.s b/lld/test/COFF/Inputs/loadconfig-arm64ec.s
index 548634cfcfb4fa..92e052a62771f5 100644
--- a/lld/test/COFF/Inputs/loadconfig-arm64ec.s
+++ b/lld/test/COFF/Inputs/loadconfig-arm64ec.s
@@ -26,6 +26,7 @@ __guard_dispatch_icall_fptr:
         .xword 0
 __os_arm64x_dispatch_call_no_redirect:
         .xword 0
+        .globl __os_arm64x_dispatch_ret
 __os_arm64x_dispatch_ret:
         .xword 0
 __os_arm64x_check_call:
diff --git a/lld/test/COFF/arm64ec-pdb.test b/lld/test/COFF/arm64ec-pdb.test
index 97b77039153c6f..d2d3efcbae78d1 100644
--- a/lld/test/COFF/arm64ec-pdb.test
+++ b/lld/test/COFF/arm64ec-pdb.test
@@ -74,15 +74,15 @@ CHECK-NEXT: pdb file ni: 1 `{{.*}}out.pdb`, src file ni: 0 ``
 CHECK:                             Public Symbols
 CHECK-NEXT: ============================================================
 CHECK-NEXT:   Records
-CHECK-NEXT:      544 | S_PUB32 [size = 28] `x86_64_sym`
+CHECK-NEXT:      584 | S_PUB32 [size = 28] `x86_64_sym`
 CHECK-NEXT:            flags = none, addr = 0005:0008
-CHECK-NEXT:      496 | S_PUB32 [size = 28] `arm64ec_sym`
+CHECK-NEXT:      536 | S_PUB32 [size = 28] `arm64ec_sym`
 CHECK-NEXT:            flags = none, addr = 0005:0000
 CHECK-NEXT:      168 | S_PUB32 [size = 44] `__hybrid_auxiliary_iat_copy`
 CHECK-NEXT:            flags = none, addr = 0002:
 CHECK-NEXT:       96 | S_PUB32 [size = 32] `__chpe_metadata`
 CHECK-NEXT:            flags = none, addr = 0003:0000
-CHECK-NEXT:      416 | S_PUB32 [size = 48] `__x64_code_ranges_to_entry_points`
+CHECK-NEXT:      456 | S_PUB32 [size = 48] `__x64_code_ranges_to_entry_points`
 CHECK-NEXT:            flags = none, addr = 0002:
 CHECK-NEXT:        0 | S_PUB32 [size = 20] `#func`
 CHECK-NEXT:            flags = function, addr = 0001:0008
@@ -90,9 +90,9 @@ CHECK-NEXT:      244 | S_PUB32 [size = 40] `__icall_helper_arm64ec`
 CHECK-NEXT:            flags = none, addr = 0001:0000
 CHECK-NEXT:       64 | S_PUB32 [size = 32] `__auximpcopy_func`
 CHECK-NEXT:            flags = none, addr = 0002:
-CHECK-NEXT:      464 | S_PUB32 [size = 32] `_load_config_used`
+CHECK-NEXT:      504 | S_PUB32 [size = 32] `_load_config_used`
 CHECK-NEXT:            flags = none, addr = 0002:
-CHECK-NEXT:      524 | S_PUB32 [size = 20] `func`
+CHECK-NEXT:      564 | S_PUB32 [size = 20] `func`
 CHECK-NEXT:            flags = function, addr = 0001:4096
 CHECK-NEXT:      128 | S_PUB32 [size = 40] `__hybrid_auxiliary_iat`
 CHECK-NEXT:            flags = none, addr = 0002:8192
@@ -106,6 +106,8 @@ CHECK-NEXT:      212 | S_PUB32 [size = 32] `__hybrid_code_map`
 CHECK-NEXT:            flags = none, addr = 0002:
 CHECK-NEXT:       20 | S_PUB32 [size = 44] `__arm64x_redirection_metadata`
 CHECK-NEXT:            flags = none, addr = 0004:0000
+CHECK-NEXT:      416 | S_PUB32 [size = 40] `__os_arm64x_dispatch_ret`
+CHECK-NEXT:            flags = none, addr = 0002:4600
 CHECK-NEXT:      316 | S_PUB32 [size = 28] `__imp_func`
 CHECK-NEXT:            flags = none, addr = 0002:8192
 
diff --git a/lld/test/COFF/lto-arm64ec.ll b/lld/test/COFF/lto-arm64ec.ll
new file mode 100644
index 00000000000000..d42bea5b87969d
--- /dev/null
+++ b/lld/test/COFF/lto-arm64ec.ll
@@ -0,0 +1,29 @@
+; REQUIRES: aarch64
+
+; RUN: llvm-as %s -o %t.obj
+; RUN: llvm-mc -filetype=obj -triple=arm64ec-windows %S/Inputs/loadconfig-arm64ec.s -o %t-loadconfig.obj
+
+; RUN: lld-link -machine:arm64ec %t.obj %t-loadconfig.obj -out:%t.exe -subsystem:console
+; RUN: llvm-objdump -d %t.exe | FileCheck %s
+
+; CHECK:      0000000140001000 <.text>:
+; CHECK-NEXT: 140001000: 00000009     udf     #0x9
+; CHECK-NEXT: 140001004: 52800020     mov     w0, #0x1                // =1
+; CHECK-NEXT: 140001008: d65f03c0     ret
+
+; CHECK:      0000000140002000 <.hexpthk>:
+; CHECK-NEXT: 140002000: 48 8b c4                     movq    %rsp, %rax
+; CHECK-NEXT: 140002003: 48 89 58 20                  movq    %rbx, 0x20(%rax)
+; CHECK-NEXT: 140002007: 55                           pushq   %rbp
+; CHECK-NEXT: 140002008: 5d                           popq    %rbp
+; CHECK-NEXT: 140002009: e9 f6 ef ff ff               jmp     0x140001004 <.text+0x4>
+; CHECK-NEXT: 14000200e: cc                           int3
+; CHECK-NEXT: 14000200f: cc                           int3
+
+target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-p:64:64-i32:32-i64:64-i128:128-n32:64-S128-Fn32"
+target triple = "arm64ec-unknown-windows-msvc"
+
+define dso_local i32 @mainCRTStartup() {
+entry:
+  ret i32 1
+}

[cjacek]

This patch introduces initial support for LTO on ARM64EC. It seems to work fine for simple cases, but I haven’t yet addressed full support. One issue is symbol mangling: currently, the bitcode files contain demangled symbol names, which get mangled during compilation. We might need to anticipate this mangling and adjust for it in BitcodeFile::parse, similar to how we create anti-dependency symbols for x86_64 object files.

Additionally, on ARM64EC, we can have a mix of x86_64 and ARM64EC bitcode files. At the moment, this will emit a warning and attempt to interpret one bitcode format as the other. We should probably handle this by splitting it into two separate compilations.

[mstorsjo]

LGTM

[cjacek]

I added the missing x86 REQUIRES (for the disassembler) and merged, thanks.