search

rust-lang / rustc_codegen_cranelift

Cranelift based backend for rustc
Apache License 2.0
1.63k stars 101 forks source link

Aarch64 macOS trap on vld1q #1534

Closed DrewRidley closed 2 months ago

DrewRidley commented 2 months ago

When building a more complex app with NEON intrinsics, I get a runtime trap on vld1q_s32. I did some searching and could not find a tracking issue upstream for this in Cranelift. I additionally tried RUSTFLAGS= "target-feature=-neon" to no avail.

trap at Instance { def: Item(DefId(2:41824 ~ core[8ff7]::core_arch::arm_shared::neon::generated::vld1q_s32_x2)), args: [] } (_ZN4core9core_arch10arm_shared4neon9generated12vld1q_s32_x217hbeca48d3375ec01eE): llvm.aarch64.neon.ld1x2.v4i32.p0i32

While I understand it is not a priority, if I could be pointed to where this set of instructions is being tracked in cranelift I would much appreciate it.

bjorn3 commented 2 months ago

The general tracking issue for this is https://github.com/rust-lang/rustc_codegen_cranelift/issues/171, but I keep issues for individual intrinsics open too. By the way do you know which crate uses this intrinsic? You should be able to get a backtrace with a debugger.

DrewRidley commented 2 months ago 
    frame #0: 0x00000001071f2808 game`_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write..write_fmt..SpecWriteFmt$GT$::spec_write_fmt::h6a3c139bdf9273a6 at mod.rs:444:32
   thread #12, name = 'Compute Task Pool (4)', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
     frame #0: 0x00000001071f2808 game`_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write..write_fmt..SpecWriteFmt$GT$::spec_write_fmt::h6a3c139bdf9273a6 at mod.rs:444:32
 Target 0: stopped.

With opt-level=0 on LLVM, I do not see that intrinsic used. It seems to get emitted regardless of optimization settings on Cranelift. I was able to trace this trap back to the crate, zune-jpeg. It has a default feature for neon that I can disable until neon support is more mature.

Thanks again for all your help!