-
Notifications
You must be signed in to change notification settings - Fork 924
Description
Hey, so we began testing wasmer's cranelift compiler on riscv64 platform as well. And just want to share something we find.
Unaligned load / store
We disallow unaligned loads / stores in our platform. So like the singlepass compiler, we hit on unaligned loads / stores immediately. I put together a fix that works for our tests. However I'm not sure if wasmer can simply include this fix. There are performance implications. Maybe it makes sense to add a feature that enables this optionally?
Difference in trapping
I notice trapping, or at least trapping triggered by some opcodes, are implemented by calling wasmer_vm_raise_trap in both LLVM compiler and singlepass compiler:
wasmer/lib/compiler-llvm/src/translator/code.rs
Lines 2471 to 2475 in bd91673
err!(self.builder.build_call( self.intrinsics.throw_trap, &[self.intrinsics.trap_unreachable.into()], "throw", )); wasmer/lib/compiler-singlepass/src/codegen.rs
Lines 3407 to 3433 in bd91673
self.machine.move_location( Size::S64, Location::Memory( self.machine.get_vmctx_reg(), self.vmoffsets .vmctx_builtin_function(VMBuiltinFunctionIndex::get_raise_trap_index()) as i32, ), Location::GPR(self.machine.get_gpr_for_call()), )?; self.emit_call_native( |this| { this.machine .emit_call_register(this.machine.get_gpr_for_call()) }, // [trap_code] [( Location::Imm32(TrapCode::UnreachableCodeReached as u32), CanonicalizeType::None, )] .iter() .cloned(), [WpType::I32].iter().cloned(), iter::empty(), NativeCallType::Unreachable, )?;
But the cranelift compiler traps simply, and relies on OS-level signal handler to process the trap.
We are running wasmer in a special environment, which can be thought as a bare-metal embedded system. So OS signal handler is not available. So the question is: is there any reason the cranelift compiler simply traps? Can we change the cranelift compiler to call wasmer_vm_raise_trap as well?
As always, thanks for the help!