Skip to content

Add Arm64_32 variant to Aarch64Architecture for arm64_32-apple-watchos#131

Merged
fitzgen merged 1 commit into
bytecodealliance:mainfrom
rebeckerspecialties:arm64_32-apple-watchos
May 12, 2026
Merged

Add Arm64_32 variant to Aarch64Architecture for arm64_32-apple-watchos#131
fitzgen merged 1 commit into
bytecodealliance:mainfrom
rebeckerspecialties:arm64_32-apple-watchos

Conversation

@matthargett
Copy link
Copy Markdown
Contributor

Summary

Adds a third Arm64_32 variant to Aarch64Architecture so the
arm64_32-apple-watchos Rust target triple round-trips through
Triple::from_str / Display.

Apple Watch Series 4+ ships an AArch64 ISA with an ILP32 ABI: 64-bit
registers, 32-bit pointers. Apple/LLVM treat the arch token as
arm64_32 (not as a gnu_ilp32-style environment qualifier the way
Linux does). The current crate exposes only Aarch64 and Aarch64be,
both hardcoded to pointer_width = U64, so any consumer that calls
Triple::from_str("arm64_32-apple-watchos") panics with
Invalid target name. There is a // TODO placeholder for this triple
in the roundtrip_known_triples test that this PR un-comments.

Why this matters

Without this patch nothing in the bytecodealliance ecosystem can build
for arm64_32-apple-watchos — wasmtime / cranelift consume
target-lexicon transitively through wasmtime-environ and others,
and their build scripts call Triple::from_str(env!(\"TARGET\")). The
panic surfaces during cargo build --target arm64_32-apple-watchos
before any target-side code is even attempted.

This is the same pattern as the existing aarch64-apple-watchos /
aarch64-apple-watchos-sim entries — those are aarch64 with U64
pointers; arm64_32 is the same ISA with U32 pointers.

What changed

  1. New variant Aarch64Architecture::Arm64_32 (with a doc comment
    explaining the Apple/LLVM naming convention).
  2. pointer_width() returns U32 for the new variant, U64 for the
    existing two — preserving the doc note that this method is
    normally arch-only and ILP32-blind, with an explicit carve-out for
    arm64_32 (which Apple models as its own arch, not via environment).
  3. endianness() returns Little.
  4. into_str() returns \"arm64_32\" so Display / to_string()
    round-trip the original token.
  5. is_thumb() returns false (consistent with the other AArch64
    variants).
  6. Aarch64Architecture::FromStr accepts \"arm64_32\".
  7. The known-triples test list at `src/targets.rs` un-comments the
    \"arm64_32-apple-watchos\" entry that was already there as a
    // TODO placeholder.

Test

cargo test — all 14 tests pass, including
roundtrip_known_triples which exercises the new triple.

Verified end-to-end on real hardware

This patch is one of three needed to build wasmtime+Pulley as a static
library for arm64_32-apple-watchos. The combined stack has been
deployed to a real Apple Watch SE 2 (S8 SoC, watchOS 11.6.2), where
all 11 wasm benchmarks (recursive fib, tail-call fib, sieve, CRC32,
two SIMD matmuls, convolution, audio-DSP, bulk-memory, call_indirect)
run with byte-identical results to their host references.

Apple Watch from Series 4 onward uses the AArch64 ISA with an ILP32
ABI (32-bit pointers, 64-bit registers), exposed via the
`arm64_32-apple-watchos` Rust target triple. The `arm64_32` arch token
isn't a `gnu_ilp32`-style environment qualifier — Apple/LLVM treat it
as its own architecture name — so model it as a third variant of
`Aarch64Architecture` with `pointer_width() = U32` and
`endianness() = Little`.

Also enables the `arm64_32-apple-watchos` entry in the
roundtrip_known_triples test (previously commented out as TODO).
@alexcrichton
Copy link
Copy Markdown
Member

cc @fitzgen, would you be able to review/merge this?

Copy link
Copy Markdown
Member

@fitzgen fitzgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@fitzgen fitzgen merged commit 2d53442 into bytecodealliance:main May 12, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants