Tracking issue for abi-cafe failures

[bjorn3]

https://github.com/rust-lang/rustc_codegen_cranelift/blob/master/patches/0002-abi-cafe-Disable-broken-tests.patch

• aarch64-unknown-linux-gnu
  • F32Array with extern "C"
  • OptionU128 with extern "Rust" and repr(C) (Return values larger than 2 registers using a return area pointer rust#131211)
• aarch64-apple-darwin
  • SingleVariantUnion with extern "C" and repr(C)
  • OptionU128 with extern "Rust" and repr(C)
• x86_64 unix
  • OptionU128 with extern "Rust" and repr(Rust) (Return values larger than 2 registers using a return area pointer rust#131211)
• x86_64-pc-windows-msvc
  • OptionU128 with extern "Rust" (Return values larger than 2 registers using a return area pointer rust#131211)
  • simple with extern "Rust"

[bjorn3]

rust-lang/rust#131211 which will be in next nightly fixed the OptionU128 issues on at least x86_64-unknown-linux-gnu and aarch64-unknown-linux-gnu and likely on macOS and Windows too.

[bjorn3]

On aarch64-unknown-linux-gnu

extern "C" {
    fn write_val(val: f32);
}

#[repr(C)]
#[derive(Copy, Clone)]
struct F32Array {
    field0: [f32; 4],
}

#[no_mangle]
pub unsafe extern "C" fn val_in_3(_: F32Array, _: F32Array, arg2: F32Array) {
    unsafe {
        write_val(arg2.field0[0]);
        write_val(arg2.field0[1]);
        write_val(arg2.field0[2]);
        write_val(arg2.field0[3]);
    }
}

produces the following LLVM ir:

define void @val_in_3([4 x float] %0, [4 x float] %1, [4 x float] %2) unnamed_addr #0 !dbg !6 {
  %.fca.0.extract9 = extractvalue [4 x float] %2, 0
  %.fca.1.extract10 = extractvalue [4 x float] %2, 1
  %.fca.2.extract11 = extractvalue [4 x float] %2, 2
  %.fca.3.extract12 = extractvalue [4 x float] %2, 3
  tail call void @write_val(float noundef %.fca.0.extract9) #1, !dbg !11
  tail call void @write_val(float noundef %.fca.1.extract10) #1, !dbg !12
  tail call void @write_val(float noundef %.fca.2.extract11) #1, !dbg !13
  tail call void @write_val(float noundef %.fca.3.extract12) #1, !dbg !14
  ret void, !dbg !15
}

declare void @write_val(float noundef) unnamed_addr #0

and the following clif ir:

function u0:0(f32, f32, f32, f32, f32, f32, f32, f32, f32, f32, f32, f32) system_v {
; kind  loc.idx   param    pass mode                            ty
; zst   _0    ()                                0b 1, 8              align=8,offset=
; ret   _0      -          Ignore                               ()
; arg   _1      = v0,v1,v2,v3 Cast { pad_i32: false, cast: CastTarget { prefix: [None, None, None, None, None, None, None, None], rest: Uniform { unit: Reg { kind: Float, size: Size(4 bytes) }, total: Size(16 bytes), is_consecutive: true }, attrs: ArgAttributes { regular: , arg_ext: None, pointee_size: Size(0 bytes), pointee_align: None } } } F32Array
; arg   _2      = v4,v5,v6,v7 Cast { pad_i32: false, cast: CastTarget { prefix: [None, None, None, None, None, None, None, None], rest: Uniform { unit: Reg { kind: Float, size: Size(4 bytes) }, total: Size(16 bytes), is_consecutive: true }, attrs: ArgAttributes { regular: , arg_ext: None, pointee_size: Size(0 bytes), pointee_align: None } } } F32Array
; arg   _3      = v8,v9,v10,v11 Cast { pad_i32: false, cast: CastTarget { prefix: [None, None, None, None, None, None, None, None], rest: Uniform { unit: Reg { kind: Float, size: Size(4 bytes) }, total: Size(16 bytes), is_consecutive: true }, attrs: ArgAttributes { regular: , arg_ext: None, pointee_size: Size(0 bytes), pointee_align: None } } } F32Array

; ........................
}

I'm pretty sure that the issue is that the [f32; 4] gets splatted into individual arguments which get a register or stack location assigned independently, while the ABI requires them to be assigned to either consecutive registers or to the stack as a whole.

Edit: Opened bytecodealliance/wasmtime#9509

[bjorn3]

Opened bytecodealliance/wasmtime#9510 to suggest removing the broken implicit return area pointer support of Cranelift to avoid others hitting the same issue.

[bjorn3]

rust-lang/compiler-builtins#735 + rust-lang/rust#134338 will make the abi of __rust_u/i128_mulo less of a special case with respect to other 128bit int intrinsics on Windows. And rust-lang/rust#134290 will make 128bit ints get returned in xmm0 once it lands. This may be switched back in the future if clang changes too.

[bryancostanich]

RFC: aarch64 HFA support in Cranelift

cc @bjorn3

I've been digging into the cranelift-on-macOS story for a Bevy project, and I keep landing back at #1525 as the gating issue. The remaining ABI failures all share a root cause that I think is worth fixing properly rather than patching around. I'd like to propose a fix and get your read on the shape before I write any code.

This is a draft — I'm specifically looking for feedback on Section 8 (open questions) before starting implementation.

Tracking: #1525, bytecodealliance/wasmtime#9509

---

1. What I'm seeing

Cranelift's aarch64 ABI lowering doesn't implement AAPCS64 §5.9.5 (Homogeneous Floating-point Aggregates). When cg_clif lowers a Rust function that takes or returns a struct shaped like [f32; 4] or repr(C) struct { a: f32, b: f32, c: f32, d: f32 }, it splats the aggregate into N individual scalar AbiParams. Cranelift's compute_arg_locs then walks each one independently through next_vreg, treating them as N unrelated f32 args.

That's wrong against AAPCS64 in two ways:

1. Atomicity. §5.9.5 says an HFA of N elements (N ∈ {1,2,3,4}) of identical FP type has to be assigned to N consecutive vector registers in v0..v7, allocated as a unit. The current code lets each element pick up next_vreg independently, which can interleave with other args and put HFA elements in non-consecutive slots.

2. NSAA spillover rule. If the HFA can't fit entirely in remaining vregs (next_vreg + N > 8), the whole aggregate has to spill to the stack AND next_vreg jumps to 8 — no further FP args can use registers either. The current code will happily put part of the aggregate in regs and part on the stack, then keep allocating subsequent FP args into vregs.

Your reproducer (from #1525)

This is your example, included for context:

extern "C" { fn write_val(val: f32); }

#[repr(C)]
#[derive(Copy, Clone)]
struct F32Array {
    field0: [f32; 4],
}

#[no_mangle]
pub unsafe extern "C" fn val_in_3(_: F32Array, _: F32Array, arg2: F32Array) {
    unsafe {
        write_val(arg2.field0[0]);
        write_val(arg2.field0[1]);
        write_val(arg2.field0[2]);
        write_val(arg2.field0[3]);
    }
}

The clif IR cg_clif emits is:

function u0:0(f32, f32, f32, f32, f32, f32, f32, f32, f32, f32, f32, f32) system_v {
; arg _1 = v0,v1,v2,v3 Cast { ... is_consecutive: true }
; arg _2 = v4,v5,v6,v7 Cast { ... is_consecutive: true }
; arg _3 = v8,v9,v10,v11 Cast { ... is_consecutive: true }

The is_consecutive: true annotation is cg_clif-internal metadata. As far as I can tell, it doesn't survive into Cranelift IR — Cranelift just sees system_v(f32, f32, ...), twelve independent f32 params. The current happy result (v0..v11 in order) is accidental; any non-FP arg interleaved between them, or enough FP register pressure to force spillover, would silently produce wrong code.

Failure mode

Silent value corruption at function boundaries. No crash, no compile-time signal — the binary just disagrees with LLVM-built code at FFI boundaries. That's the worst class of ABI bug because there's nothing to point at without a reproducer.

Where the code lives

It's cranelift/codegen/src/isa/aarch64/abi.rs, in AArch64MachineDeps::compute_arg_locs. The current "multi reg" path has an explicit assertion that closes the door on anything beyond two registers:

let is_multi_reg = rcs.len() >= 2;
if is_multi_reg {
    assert!(
        rcs.len() == 2,
        "Unable to handle multi reg params with more than 2 regs"
    );
    assert!(
        rcs == &[RegClass::Int, RegClass::Int],
        "Unable to handle non i64 regs"
    );
    ...
}

That branch only handles 128-bit ints (i128 → two x-regs). There's nothing in this file that even considers HFAs.

---

2. What I propose

Add an optional aggregate field to AbiParam in cranelift/codegen/src/ir/extfunc.rs:

#[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)]
#[cfg_attr(feature = "enable-serde", derive(Serialize, Deserialize))]
pub struct AbiParam {
    pub value_type: Type,
    pub purpose: ArgumentPurpose,
    pub extension: ArgumentExtension,
    #[cfg_attr(feature = "enable-serde", serde(default))]
    pub aggregate: Option<AggregateGroup>,
}

#[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)]
#[cfg_attr(feature = "enable-serde", derive(Serialize, Deserialize))]
pub struct AggregateGroup {
    /// Unique identifier for this aggregate within the enclosing Signature.
    /// Frontends are responsible for assigning fresh group_ids per aggregate.
    pub group_id: u16,
    /// 0-based position of this scalar within the aggregate.
    pub index: u8,
    /// Total elements in the aggregate (1..=16, but only 1..=4 meaningful for HFA).
    pub total: u8,
    pub kind: AggregateKind,
}

#[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)]
#[cfg_attr(feature = "enable-serde", derive(Serialize, Deserialize))]
pub enum AggregateKind {
    /// Homogeneous Floating-point Aggregate per AAPCS64 §5.9.5 / Apple ARM64 ABI.
    /// All elements in the group must share the same FP `value_type`.
    /// Targets that recognize this kind allocate consecutive FP regs atomically.
    Hfa,
}

I considered a couple alternatives and I think this shape is the right trade-off:

Why a field, not a new ArgumentPurpose variant. ArgumentPurpose gets matched exhaustively all over the codebase, including downstream consumers. Adding a variant is a wider blast radius than adding an optional field whose default (None) is a no-op for everyone who doesn't opt in.

Why a target-independent annotation. HFA semantics are aarch64-specific (and PowerPC ELFv2 in the same family), but AbiParam lives in target-independent IR. The frontend (cg_clif) is the layer that knows the Rust type semantics and already varies by target — emitting aggregate: Some(...) only when targeting aarch64 is a frontend-side decision. Other backends consume the IR and either ignore the field or assert it's None.

Why not first-class struct/array param types. Cranelift has explicitly avoided aggregate types in its IR as a design principle. I don't want to relitigate that. The annotation approach lets the frontend keep splatting (preserves the current IR contract) while passing along enough info for the backend to reassemble the AAPCS64-required atomic decision.

---

3. aarch64 lowering, in detail

In compute_arg_locs:

Pre-pass: build a group index

Before the per-param loop, scan params and group by aggregate.group_id:

let mut hfa_groups: BTreeMap<u16, Vec<usize>> = BTreeMap::new();
for (i, p) in params.iter().enumerate() {
    if let Some(g) = p.aggregate {
        hfa_groups.entry(g.group_id).or_default().push(i);
    }
}

Per-group validation (debug assertions)

For each group:

• members.len() == first.total
• first.total ∈ 1..=4 (HFA limit)
• members[k].aggregate.unwrap().index == k (in order)
• All members share the same value_type
• value_type is F32 or F64 (HFA covers single/double; F16/F128 are out of scope for v1)

These are debug assertions because if they fail, the frontend made a mistake — it's not something the backend should silently fix up.

Group allocation rule (AAPCS64 §5.9.5)

For an HFA group of N elements:

1. Fits in remaining vregs: if next_vreg + N <= 8, allocate vregs next_vreg..next_vreg + N as one ABIArg::Slots with N ABIArgSlot::Reg entries. Then next_vreg += N.

2. Doesn't fit: per the NSAA rule, set next_vreg = 8 (no further FP-reg allocation for this signature). Allocate the whole aggregate on the stack as N consecutive ABIArgSlot::Stack entries at elem_size offsets, with the start aligned to elem_size (or 8 bytes per AAPCS64, whichever is larger — for f32/f64 this comes out to 8).

Apple ARM64 ABI

Apple matches AAPCS64 for HFAs in fixed (non-variadic) argument position. Variadic ... HFAs get passed differently (each element on the stack, no register use). I'm scoping v1 to fixed args only; frontends shouldn't emit aggregate: Some(...) on variadic params for apple_aarch64 call_conv. If we want variadic support later, it's a small addition.

Returns

Returns go through the same compute_arg_locs with args_or_rets == ArgsOrRets::Rets and a fresh next_vreg = 0. The HFA pre-pass and group rule apply identically. An HFA-shaped return of up to 4 elements lands in v0..v3.

---

4. Other backends

compute_arg_locs exists on every backend. For backends that don't yet implement HFA handling, I think we should explicitly reject the annotation rather than silently mishandle it. Add at the top of each backend's per-param loop:

assert!(
    param.aggregate.is_none(),
    "AggregateGroup hint not yet supported on this backend; \
     frontend must not emit aggregate hints for this target"
);

Backends to update:

• cranelift/codegen/src/isa/x64/abi.rs
• cranelift/codegen/src/isa/riscv64/abi.rs
• cranelift/codegen/src/isa/s390x/abi.rs
• cranelift/codegen/src/isa/pulley_shared/abi.rs

x86_64 SysV has its own thing for XMM splatting of __m128-shaped aggregates, but the rules are different enough that I don't think it's worth trying to unify. If x86_64 wants to consume the same annotation later with its own interpretation, the field is already there.

---

5. Text format

Extend the parser/printer to support an hfa(group_id, index, total) token after the type:

function %hfa_args(f32 hfa(0,0,4), f32 hfa(0,1,4), f32 hfa(0,2,4), f32 hfa(0,3,4)) -> f32 {
block0(v0: f32, v1: f32, v2: f32, v3: f32):
    return v0
}

function %hfa_ret() -> f32 hfa(0,0,4), f32 hfa(0,1,4), f32 hfa(0,2,4), f32 hfa(0,3,4) {
    ...
}

Grammar:

abi_param := type [extension] [purpose] [aggregate_annotation]
aggregate_annotation := "hfa" "(" u16 "," u8 "," u8 ")"

Round-trip lossless via parser + printer.

---

6. Migration

• Source-level: AbiParam::new(ty) keeps defaulting aggregate: None. Existing code constructing AbiParam { ... } literally will need aggregate: None added — that's a build break we'd fix in the same commit.
• Serde: #[serde(default)] on the new field lets older serialized signatures deserialize cleanly.
• Bytecode/clif text: files without hfa(...) annotations parse to aggregate: None. No existing test or production .clif file changes meaning.
• Hashing: AbiParam derives Hash. Adding the field changes the hash even when it's None. wasmtime's compilation cache will see invalidations on the first run after upgrade — worth a release-notes mention but I don't think it's blocking.

---

7. Test plan

Unit tests

• AbiParam::with_aggregate round-trip: construct, format, parse, compare.
• Parser accepts hfa(g,i,n).
• Printer emits hfa(g,i,n) after the type.

Filetests (cranelift/filetests/filetests/isa/aarch64/)

• hfa-args.clif — [f32;4] lands in v0..v3.
• hfa-args-mixed.clif — int args + HFA, validate vreg allocation is independent of xreg allocation.
• hfa-spill.clif — 6 leading f32 scalars consume v0..v5; HFA of 4 can't fit; whole HFA to stack; trailing f32 also to stack (NSAA rule).
• hfa-return.clif — HFA of 4 f32 returned in v0..v3.
• hfa-apple.clif — Apple call_conv, fixed HFA args match AAPCS64.
• hfa-bjorn3-1525.clif — your exact reproducer, 3× [f32;4] args, validates each group is allocated atomically.

abi-cafe

Run abi-cafe on aarch64-apple-darwin and aarch64-unknown-linux-gnu with the HFA test corpus. Compare cg_clif (with this change + corresponding cg_clif change) to clang. Previously failing F32Array-shaped tests should agree.

---

8. Open questions — would love your input here

These are the things I want to nail down before writing implementation code. Strong opinions welcome:

1. Field vs. variant. Is Option<AggregateGroup> on AbiParam the right shape, or do you prefer extending ArgumentPurpose with an AggregateElement(AggregateGroup) variant? I lean field-on-AbiParam because the variant approach forces every exhaustive match across the codebase to learn about HFAs, but I can see the argument the other way.

2. AggregateKind granularity. Should AggregateKind start with just Hfa, or include placeholders like Hva (Homogeneous Vector Aggregate, AAPCS64 §5.9.5.2) we don't yet implement? Easier to add later, but then the IR change ships twice.

3. ArgsAccumulator 1-to-1 invariant. This is the one I'd most like your read on. The current API expects one ABIArg push per input AbiParam. An HFA group folds N params into 1 multi-slot ABIArg. Two ways to handle it:

   • (a) Push N-1 zero-slot dummy ABIArgs to keep the count aligned. Ugly but local.
   • (b) Refactor ArgsAccumulator so one param can map to one ABIArg even when it represents N elements, by exposing an explicit "map indices" structure. Cleaner but widens the patch.

   I lean (b) for cleanliness, but it's a bigger change. Your call would settle it.

4. Args + returns in one RFC, or split? Args alone is the bulk of the surface and the bug fix; returns are smaller. Bundling simplifies the test story but enlarges the patch. Splitting lets args land first.

5. Frontend contract. I've been writing this assuming "frontend must not emit aggregate hints for backends that don't support them," enforced by debug asserts in non-aarch64 backends. Strict-enough? Or do you want a backend capability query so the frontend can ask "do you handle Hfa?" rather than hard-coding target awareness?

6. Variadic args for v1. I've scoped variadic HFA args (the Apple ARM64 quirk) out of v1. OK with you, or should v1 cover them too?

---

9. Implementation plan

I have a step-by-step implementation plan written up locally. It covers:

• Phase 0: branch + baseline (done locally — 113 aarch64 filetests passing on baseline)
• Phase 1: this RFC
• Phase 2: IR changes + parser + non-aarch64 backend asserts
• Phase 3: aarch64 compute_arg_locs HFA implementation + filetests (args, spill, return, Apple)
• Phase 4: end-to-end validation including your reproducer + abi-cafe
• Phase 5: cg_clif integration (separate plan, separate PR)
• Phase 6: PR submission

Estimated patch size: ~600–1000 LOC across ~10 files in wasmtime, plus a smaller follow-up in rustc_codegen_cranelift to emit the new annotation. Happy to share the plan if it's useful.

---

10. Why I'm working on this

This is the gating issue keeping bevyengine/bevy-website#1543 ("Recommend cranelift on macOS") open, which is what brought me here. Fixing it unblocks Cranelift's recommendation for macOS aarch64 — the platform with probably the largest population of Rust devs wanting faster debug compiles, and where Cranelift's compile-time advantage over LLVM is most pronounced. It also unblocks general adoption of Cranelift for Rust code crossing FFI boundaries on aarch64, which is a wider concern.

Looking forward to your read on Section 8 before I start writing code.

[bjorn3]

#[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)]
#[cfg_attr(feature = "enable-serde", derive(Serialize, Deserialize))]
pub enum AggregateKind {
/// Homogeneous Floating-point Aggregate per AAPCS64 §5.9.5 / Apple ARM64 ABI.
/// All elements in the group must share the same FP value_type.
/// Targets that recognize this kind allocate consecutive FP regs atomically.
Hfa,
}

LLVM does not distinguish between aggregate kinds at all when encoding them in LLVM IR.

This is a very verbose comment with a couple of things that seem a bit weird for human text. Did you use AI to generate it?