Cranelift caller gets wrong Quat from LLVM callee on Win64

[Maxime-Verrier]

Summary

Had a mesh rendering with the wrong rotation in my Bevy game. Traced it
down to glam::Quat::from_rotation_x(-FRAC_PI_2) returning a different
value under cranelift than under LLVM, but only when a cranelift crate is
calling into an LLVM-compiled glam.

Quat is #[repr(C, align(16))] over [f32; 4]. Under pure LLVM the call
returns (-sqrt(2)/2, 0, 0, sqrt(2)/2) like you'd expect. Under the mixed
build the value just comes back wrong. No panic, no link warning.

Configs I tried

Bevy 0.17, rustc nightly:

workspace	deps	link	target	result
cranelift	llvm	dylib	x86_64-pc-windows-gnu	wrong
cranelift	llvm	static	x86_64-pc-windows-gnu	wrong
cranelift	llvm	static	x86_64-pc-windows-msvc	wrong
llvm	llvm	dylib	x86_64-pc-windows-gnu	correct
llvm	llvm	static	x86_64-pc-windows-gnu	correct
cranelift	cranelift	static	x86_64-pc-windows-gnu	correct

Every failing row has a cranelift caller invoking an LLVM callee. Doesn't
matter whether it's static or DLL, gnu or msvc. A friend runs the same
cranelift-workspace + LLVM-deps + bevy dynamic_linking setup on
x86_64-unknown-linux-gnu with no issues, so this looks Win64-specific.

Couldn't test

• cranelift deps + dylib: won't link, looks like a separate dllexport gap
  in cg_clif.
• cranelift + msvc + dylib: won't link, blocked by link error: undefined symbol in Window msvc : link dynamic library #1610.
• Other types (Vec3, Transform, custom structs): haven't tested. Could
  be one cell of a wider mismatch or specific to 16-byte-aligned [f32; 4].

Related

• Tracking issue for abi-cafe failures #1525 (abi-cafe failures): same family, but I haven't run abi-cafe to
  check whether this specific combo shows up there.
• Bevy dynamic-linking makes the program crash #1530 (runtime failures with dynamic_linking): same config family,
  different symptom (crash vs wrong value). My matrix shows
  dynamic_linking isn't required for this one.

Can cut a smaller repo without Bevy if it'd help.