Allow the LLVM backend to target AArch64

[dougchansan]

What

dolllvm_emit_object rejected every triple that was not x86-64:

if (triple.getArch() != llvm::Triple::x86_64 || ...)
  fprintf(diagnostics, "dolllvm: supported production targets are x86-64 Linux and Windows\n");

This accepts AArch64 as well.

Why it is safe

The gate looked like a support policy rather than a technical limit, and the code bears that out — the function emitter and both lowering files contain no x86-specific code:

• no inline asm anywhere in src/backend/llvm/
• functions are emitted with CallingConv::C
• the target machine already comes from getDefaultTargetTriple() / getHostCPUName()
• CMake already links the native / nativecodegen LLVM components

So the IR is target-neutral and LLVM codegens AArch64 objects without further changes.

Verification

Raspberry Pi 4 (Cortex-A72), Debian clang/LLVM 19.1.7, against Luigi's Mansion (GLME01) — a 530,648-instruction DOL, 4164 chunks:

check	result
object output	ELF 64-bit LSB relocatable, ARM aarch64
module loads under ModernGekko	yes
rendering	correct (in-game scene renders normally)
smc_failed	0
GX FIFO errors	0
framerate vs C backend, same scene	19.51 vs 19.46 FPS

Runtime counters differ from the C backend as you would expect from a different codegen path, and notably the LLVM backend took zero hook fallbacks against the C backend's 196:

llvm : native=1669  hook_fb=0    verifications=22  bursts=81
c    : native=1974  hook_fb=196  verifications=5   bursts=63

On that framerate number

19.5 FPS is a fixed comparison point, not a figure for the game. Framerate on this hardware is strongly scene-dependent: the mansion foyer used for the benchmark is a heavy scene, title and cutscene sequences run roughly 30–60 FPS, and other rooms are measurably faster. Both backends were measured on the identical savestate, scene, clock and settings, with a fixed 300-second frame-verified window — the point is parity between backends, not the absolute value.

Scope

This enables the target; it is not a performance change. On this workload the AArch64 LLVM backend measured the same as the C backend (the bottleneck there is L1-icache pressure, which codegen does not move). Flagging that explicitly so the change is judged on correctness rather than on a speed claim.

x86-64 behaviour is unchanged.