[ARM64EC 2/?] Add target triple, and allow targeting it.

[efriedma]

Summary

Part of patchset to add initial support for ARM64EC.

Per discussion on review, using the triple arm64ec-pc-windows-msvc. The parsing works the same way as Apple's alternate Arm ABI "arm64e".

[mstorsjo]

For lack of any better idea, I'm using the triple aarch64-pc-windows-msvc_arm64ec. Suggestions for a better name welcome... or if you think I should use some other mechanism to distinguish.

I'm not 100% sold on using msvc_arm64ec like this... If we'd want to use this ABI mode for mingw targets too (not quite sure right now if it's doable and something that one wants to do at some point, or if it ties in to too many other MSVC specifics), I guess that would have to be another separate target like ...-gnu_arm64ec - using up yet another entry in enum EnvironmentType for it.

Another potential option could be to use subarches, like is done in apple toolchains, for selecting different ABIs within the same architecture, like armv7k and arm64e there. I presume that blocks using that field for finer details, like armv8.5a though (not sure how common that is).

[DavidSpickett]

There is one reference in llvm to arm64-pc-windows-msvc (llvm/test/tools/llvm-lib/Inputs/arm64.ll) so I assume there is some mapping between arm64 -> aarch64 naming. So perhaps "arm64ec-pc-windows" like Apple has "arm64e-apple-darwin"? Internally converted to aarch64ec-pc-windows-msvc. Is there a big reason to put the EC bit on the end?

(I am fuzzy on the rules, if any for tripples/quadruples)

Another potential option could be to use subarches, like is done in apple toolchains, for selecting different ABIs within the same architecture, like armv7k and arm64e there. I presume that blocks using that field for finer details, like armv8.5a though (not sure how common that is).

Finer details I'd expect to be specified by -march or -mcpu. Though we do handle things like "thumbv7" vs "thumbv8" which is a similar kind of detail (you could -mthumb -march=armv(7|8)-a instead).

[efriedma]

If we'd want to use this ABI mode for mingw targets too [...], I guess that would have to be another separate target like ...-gnu_arm64ec - using up yet another entry in enum EnvironmentType for it.

Yes, you'd have to do something like that.

We could do something like arm64ec-pc-windows-msvc, I guess. That sort of goes against the spirit of target triples: the first part is usually used to describe the instruction set, and the fourth part is usually used to describe alternate ABI/environment/etc. It's not like "arm64ec" makes sense anywhere other than Windows, anyway.

Of course, everything related to triples is a bit fuzzy; if we want to use AArch64SubArch_arm64ec, there isn't really anything stopping us.

(not quite sure right now if it's doable and something that one wants to do at some point, or if it ties in to too many other MSVC specifics),

Not sure if I'm going to end up hooking up ARM64EC support in lld. And I'm not sure if any of the runtime libraries need to be linked in statically. Otherwise, I don't see any reason you couldn't add support to mingw.

I presume that blocks using that field for finer details, like armv8.5a though (not sure how common that is).

We don't really do that sort of thing on aarch64, only 32-bit ARM. See also parseSubArch() in Triple.cpp.

[dpaoliello]

We could do something like arm64ec-pc-windows-msvc, I guess. That sort of goes against the spirit of target triples: the first part is usually used to describe the instruction set, and the fourth part is usually used to describe alternate ABI/environment/etc. It's not like "arm64ec" makes sense anywhere other than Windows, anyway.

Of course, everything related to triples is a bit fuzzy; if we want to use AArch64SubArch_arm64ec, there isn't really anything stopping us.

I would prefer it if we used a different first part to indicate that Arm64EC is a different "architecture" than AArch64.

From a theoretical perspective, Arm64EC is a mix of AArch64 and x86_64: one can think of it as a weird processor that can run both AArch64 code (with some caveats, like the restricted registers) and x86_64 code, even if LLVM is only ever emitting AArch64 (which may not be true in the future if support for x86_64 assembly is added).

From a practical perspective, MSVC uses a distinct set of architecture-specific preprocessor macros for Arm64EC vs AArch64: https://techcommunity.microsoft.com/t5/windows-kernel-internals-blog/getting-to-know-arm64ec-defines-and-intrinsic-functions/ba-p/2957235. Other languages should follow this pattern (i.e., disabling code that is targeted to AArch64 and instead enabling Arm64EC-specific code - whether x86_64 code is also enabled is debatable), and having a different "architecture" part to the target-triple is an excellent way to signal this.

[mstorsjo]

In D125412#3548237, @dpaoliello wrote:

We could do something like arm64ec-pc-windows-msvc, I guess. That sort of goes against the spirit of target triples: the first part is usually used to describe the instruction set, and the fourth part is usually used to describe alternate ABI/environment/etc. It's not like "arm64ec" makes sense anywhere other than Windows, anyway.

Of course, everything related to triples is a bit fuzzy; if we want to use AArch64SubArch_arm64ec, there isn't really anything stopping us.

I would prefer it if we used a different first part to indicate that Arm64EC is a different "architecture" than AArch64.

From a theoretical perspective, Arm64EC is a mix of AArch64 and x86_64: one can think of it as a weird processor that can run both AArch64 code (with some caveats, like the restricted registers) and x86_64 code, even if LLVM is only ever emitting AArch64 (which may not be true in the future if support for x86_64 assembly is added).

From a practical perspective, MSVC uses a distinct set of architecture-specific preprocessor macros for Arm64EC vs AArch64: https://techcommunity.microsoft.com/t5/windows-kernel-internals-blog/getting-to-know-arm64ec-defines-and-intrinsic-functions/ba-p/2957235. Other languages should follow this pattern (i.e., disabling code that is targeted to AArch64 and instead enabling Arm64EC-specific code - whether x86_64 code is also enabled is debatable), and having a different "architecture" part to the target-triple is an excellent way to signal this.

Veering slightly offtopic here, but - I'm curious - is it possible to link in regular aarch64 object files in an arm64ec executable (for functions where the calling convention doesn't differ from regular aarch64)? Those object files would only ever be called from arm64ec code (not from x86_64), so I wonder if it would work without all the thunks that are present in arm64ec object files. (In particular, the case I have in mind is cases with handwritten aarch64 assembly.) Would it be possible to mark such functions with a calling convention attribute on the C level, to let the compiler generate code for calling regular aarch64 functions?

[dpaoliello]

Veering slightly offtopic here, but - I'm curious - is it possible to link in regular aarch64 object files in an arm64ec executable (for functions where the calling convention doesn't differ from regular aarch64)? Those object files would only ever be called from arm64ec code (not from x86_64), so I wonder if it would work without all the thunks that are present in arm64ec object files. (In particular, the case I have in mind is cases with handwritten aarch64 assembly.) Would it be possible to mark such functions with a calling convention attribute on the C level, to let the compiler generate code for calling regular aarch64 functions?

Caveat: I'm not an expert in this area, but this is my understanding of the docs: https://docs.microsoft.com/en-us/windows/arm/arm64ec-abi.

It's not a good idea to mix Arm64EC and normal AArch64:

• The set of registers that Arm64EC uses is restricted to those that can be mapped to x86_64, this allows the Windows Kernel to capture them in an x86_64-compatible CONTEXT object (in case x86_64 code wants to inspect that context). So, if you are running normal AArch64 code and the kernel has to save off and then restore your context, the non-mapped registers' values may be lost.
• The variadic calling convention is different: https://docs.microsoft.com/en-us/windows/arm/arm64ec-abi#variadic-calling-convention.
• If your function accepts a function pointer, how does it know if it is an AArch64 or x86_64 function? Hence call checkers are mandatory: https://docs.microsoft.com/en-us/windows/arm/arm64ec-abi#call-checkers.
• There's also differences with the stack and security cookie checkers: https://docs.microsoft.com/en-us/windows/arm/arm64ec-abi#stack-checkers.

But, if you're hand-coding assembly, you could avoid the cases above (i.e., restrict the registers you use, avoid variadic functions, avoid indirect calls, avoid stack checks and avoid security cookie checks) to create assembly code that is usable in both Arm64EC and normal AArch64 contexts.

As for the thunks:

• You only require Exit Thunks for code that *might* be calling to x86_64 code. If you statically know that all of the functions that your code calls are AArch64, then Exit Thunks are not required.
• Same goes for the Entry Thunks: if you statically know that the only functions that call your code are AArch64, then Entry Thunks are not required.

[mstorsjo]

In D125412#3548322, @dpaoliello wrote:

It's not a good idea to mix Arm64EC and normal AArch64:

• The set of registers that Arm64EC uses is restricted to those that can be mapped to x86_64, this allows the Windows Kernel to capture them in an x86_64-compatible CONTEXT object (in case x86_64 code wants to inspect that context). So, if you are running normal AArch64 code and the kernel has to save off and then restore your context, the non-mapped registers' values may be lost.

Thanks - this is probably the most tricky limitation, if registers outside of that set can be lost essentially at any time, asynchronously. I take it that they’re not clobbered on e.g. regular OS context switches, but mainly when the OS interacts with the running thread (e.g. if executing an APC).

[efriedma]

Switched triple to arm64ec-pc-windows-msvc

[bcl5980]

We may need to add arm64ec into llvm\utils\UpdateTestChecks\asm.py to make update_*_test_checks.py work.

       'arm64': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_RE),
       'arm64e': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),
+      'arm64ec': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_RE),
       'arm64-apple-ios': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),

[mstorsjo]

LGTM

[bcl5980]

llvm/test/MC/AArch64/arm64ec.s

2

arm64ec-pc-windows-msvc or arm64ec-pc-windows-msvc_arm64ec here?

[mstorsjo]

llvm/test/MC/AArch64/arm64ec.s

2

Oh, good catch, thanks - indeed this should be changed to arm64ec-pc-windows-msvc.

llvm/include/llvm/ADT/Triple.h

enum SubArchType {
     ARMSubArch_v6m,
     ARMSubArch_v6k,
     ARMSubArch_v6t2,
     ARMSubArch_v5,
     ARMSubArch_v5te,
     ARMSubArch_v4t,
 
     AArch64SubArch_arm64e,
+    AArch64SubArch_arm64ec,
 
     KalimbaSubArch_v3,
     KalimbaSubArch_v4,
     KalimbaSubArch_v5,
 
     MipsSubArch_r6,
 
     PPCSubArch_spe,
public:
   }
 
   /// Checks if the environment could be MSVC.
   bool isWindowsMSVCEnvironment() const {
     return isKnownWindowsMSVCEnvironment() ||
            (isOSWindows() && getEnvironment() == Triple::UnknownEnvironment);
   }
 
+  // Checks if we're using the Windows Arm64EC ABI.
+  bool isWindowsArm64EC() const {
+    return getArch() == Triple::aarch64 &&
+           getSubArch() == Triple::AArch64SubArch_arm64ec;
+  }
+
   bool isWindowsCoreCLREnvironment() const {
     return isOSWindows() && getEnvironment() == Triple::CoreCLR;
   }
 
   bool isWindowsItaniumEnvironment() const {
     return isOSWindows() && getEnvironment() == Triple::Itanium;
   }
 

llvm/lib/Support/Triple.cpp

auto AT = StringSwitch<Triple::ArchType>(ArchName)
     .Case("xscaleeb", Triple::armeb)
     .Case("aarch64", Triple::aarch64)
     .Case("aarch64_be", Triple::aarch64_be)
     .Case("aarch64_32", Triple::aarch64_32)
     .Case("arc", Triple::arc)
     .Case("arm64", Triple::aarch64)
     .Case("arm64_32", Triple::aarch64_32)
     .Case("arm64e", Triple::aarch64)
+    .Case("arm64ec", Triple::aarch64)
     .Case("arm", Triple::arm)
     .Case("armeb", Triple::armeb)
     .Case("thumb", Triple::thumb)
     .Case("thumbeb", Triple::thumbeb)
     .Case("avr", Triple::avr)
     .Case("m68k", Triple::m68k)
     .Case("msp430", Triple::msp430)
     .Cases("mips", "mipseb", "mipsallegrex", "mipsisa32r6",
if (SubArchName.startswith("mips") &&
     return Triple::MipsSubArch_r6;
 
   if (SubArchName == "powerpcspe")
     return Triple::PPCSubArch_spe;
 
   if (SubArchName == "arm64e")
     return Triple::AArch64SubArch_arm64e;
 
+  if (SubArchName == "arm64ec")
+    return Triple::AArch64SubArch_arm64ec;
+
   if (SubArchName.startswith("spirv"))
     return StringSwitch<Triple::SubArchType>(SubArchName)
         .EndsWith("v1.0", Triple::SPIRVSubArch_v10)
         .EndsWith("v1.1", Triple::SPIRVSubArch_v11)
         .EndsWith("v1.2", Triple::SPIRVSubArch_v12)
         .EndsWith("v1.3", Triple::SPIRVSubArch_v13)
         .EndsWith("v1.4", Triple::SPIRVSubArch_v14)
         .EndsWith("v1.5", Triple::SPIRVSubArch_v15)

llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp

 namespace {
 class COFFAArch64AsmBackend : public AArch64AsmBackend {
 public:
   COFFAArch64AsmBackend(const Target &T, const Triple &TheTriple)
       : AArch64AsmBackend(T, TheTriple, /*IsLittleEndian*/ true) {}
 
   std::unique_ptr<MCObjectTargetWriter>
   createObjectTargetWriter() const override {
-    return createAArch64WinCOFFObjectWriter();
+    return createAArch64WinCOFFObjectWriter(TheTriple);
   }
 };
 }
 
 MCAsmBackend *llvm::createAArch64leAsmBackend(const Target &T,
                                               const MCSubtargetInfo &STI,
                                               const MCRegisterInfo &MRI,
                                               const MCTargetOptions &Options) {

llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.h

 class MCInstPrinter;
 class MCRegisterInfo;
 class MCObjectTargetWriter;
 class MCStreamer;
 class MCSubtargetInfo;
 class MCTargetOptions;
 class MCTargetStreamer;
 class Target;
+class Triple;
 
 MCCodeEmitter *createAArch64MCCodeEmitter(const MCInstrInfo &MCII,
                                           MCContext &Ctx);
 MCAsmBackend *createAArch64leAsmBackend(const Target &T,
                                         const MCSubtargetInfo &STI,
                                         const MCRegisterInfo &MRI,
                                         const MCTargetOptions &Options);
 MCAsmBackend *createAArch64beAsmBackend(const Target &T,
                                         const MCSubtargetInfo &STI,
                                         const MCRegisterInfo &MRI,
                                         const MCTargetOptions &Options);
 
 std::unique_ptr<MCObjectTargetWriter>
 createAArch64ELFObjectWriter(uint8_t OSABI, bool IsILP32);
 
 std::unique_ptr<MCObjectTargetWriter>
 createAArch64MachObjectWriter(uint32_t CPUType, uint32_t CPUSubtype,
                               bool IsILP32);
 
-std::unique_ptr<MCObjectTargetWriter> createAArch64WinCOFFObjectWriter();
+std::unique_ptr<MCObjectTargetWriter>
+createAArch64WinCOFFObjectWriter(const Triple &TheTriple);
 
 MCTargetStreamer *createAArch64AsmTargetStreamer(MCStreamer &S,
                                                  formatted_raw_ostream &OS,
                                                  MCInstPrinter *InstPrint,
                                                  bool isVerboseAsm);
 
 namespace AArch64_MC {
 void initLLVMToCVRegMapping(MCRegisterInfo *MRI);

llvm/lib/Target/AArch64/MCTargetDesc/AArch64WinCOFFObjectWriter.cpp

 #include <cassert>
 
 using namespace llvm;
 
 namespace {
 
 class AArch64WinCOFFObjectWriter : public MCWinCOFFObjectTargetWriter {
 public:
-  AArch64WinCOFFObjectWriter()
-      : MCWinCOFFObjectTargetWriter(COFF::IMAGE_FILE_MACHINE_ARM64) {}
+  AArch64WinCOFFObjectWriter(const Triple &TheTriple)
+      : MCWinCOFFObjectTargetWriter(TheTriple.isWindowsArm64EC()
+                                        ? COFF::IMAGE_FILE_MACHINE_ARM64EC
+                                        : COFF::IMAGE_FILE_MACHINE_ARM64) {}
 
   ~AArch64WinCOFFObjectWriter() override = default;
 
   unsigned getRelocType(MCContext &Ctx, const MCValue &Target,
                         const MCFixup &Fixup, bool IsCrossSection,
                         const MCAsmBackend &MAB) const override;
 
   bool recordRelocation(const MCFixup &) const override;
case AArch64::fixup_aarch64_pcrel_call26:
     return COFF::IMAGE_REL_ARM64_BRANCH26;
   }
 }
 
 bool AArch64WinCOFFObjectWriter::recordRelocation(const MCFixup &Fixup) const {
   return true;
 }
 
-std::unique_ptr<MCObjectTargetWriter> llvm::createAArch64WinCOFFObjectWriter() {
-  return std::make_unique<AArch64WinCOFFObjectWriter>();
+std::unique_ptr<MCObjectTargetWriter>
+llvm::createAArch64WinCOFFObjectWriter(const Triple &TheTriple) {
+  return std::make_unique<AArch64WinCOFFObjectWriter>(TheTriple);
 }

llvm/test/MC/AArch64/arm64ec.s

+// RUN: llvm-mc -triple arm64ec-pc-windows-msvc -filetype=obj %s -o - | llvm-objdump -d -r - | FileCheck %s
+// CHECK: file format coff-arm64ec
+// CHECK: add x0, x1, x2
+add x0, x1, x2