Wasmtime GitHub notifications bot (Feb 03 2026 at 13:09): Wasmtime GitHub notifications bot (Feb 03 2026 at 13:09):tage64 opened issue #12502:
I am ahead-of-time compiling wasm for RISC-V64 using Cranelift. The generated assembler performs a 64-bit load on a 4 B (not 8 B) aligned address. This is not allowed by the RISC-V spec although many processors does support it anyway. However our RISC-V implementation (NOEL-V) don't support misaligned memory accesses.
Would it be possible for Cranelift or Wasmtime to replace misaligned memory accesses with manual load/store/shift instructions to allow ahead-of-time compilation on these platforms as well?
It runs perfectly under Pulley but is ~15x slower compared to native speed.
Wasmtime GitHub notifications bot (Feb 03 2026 at 13:35):tage64 edited issue #12502:
I am ahead-of-time compiling wasm for RISC-V64 using Cranelift. The generated assembly performs a 64-bit load on a 4 B (not 8 B) aligned address. This is not allowed by the RISC-V spec although many processors does support it anyway. However our RISC-V implementation (NOEL-V) don't support misaligned memory accesses.
Would it be possible for Cranelift or Wasmtime to replace misaligned memory accesses with manual load/store/shift instructions to allow ahead-of-time compilation on these platforms as well?
It runs perfectly under Pulley but is ~15x slower compared to native speed.
Wasmtime GitHub notifications bot (Feb 03 2026 at 15:26):alexcrichton added the cranelift label to Issue #12502.
Wasmtime GitHub notifications bot (Feb 03 2026 at 15:26):alexcrichton added the cranelift:area:riscv64 label to Issue #12502.
Wasmtime GitHub notifications bot (Feb 03 2026 at 15:31):alexcrichton commented on issue #12502:
This is, in theory, possible, but it'd be a fair bit of implementation work to do. Loads are tagged as aligned or not in Cranelift meaning we semantically know when to generate instructions for a misaligned load, but right now there's no codegen rules, in any backend, for generating misaligned loads and shifting the result. Implementing this would probably require a new risc-v feature in Cranelift for "supports unaligned loads", which would encompass today's behavior, and then when that feature is disabled new rules would be added to handle the misaligned load case.
I'll note though that all loads from wasm must be assumed to have an alignment at 1 and dynamically at runtime we figure out what the alignment actually was. In the face of trapping accesses should we load too far beyond the end of an address it means that generating code for misaligned loads is probably infeasible in the long-term. I believe other wasm engines sometimes handle this use case with a signal handler that catches the misaligned access, performs the "real" accesses in the signal handler, and then resumes the instruction. Wasmtime isn't currently architected for that and would also require some significant refactoring on the Cranelift side of things to support that sort of translation.
Overall this is likely a very significant chunk of implementation work, and for the niche nature of not supporting unaligned loads it's unlikely to get resolved any time soon. I'd recommend using Pulley for now in the meantime.
Wasmtime GitHub notifications bot (Feb 03 2026 at 15:52):cfallin commented on issue #12502:
FWIW, our RISC-V backend was initially developed for the
riscv64gc-unknown-linux-gnutarget, and on Linux, misaligned loads/stores are guaranteed to work (the base ISA spec, as I'm sure you know, leaves it up to the EEI (execution environment interface)). This may not help you if you're targeting an embedded environment of some sort with ano_stdWasmtime build but it at least gives an idea of our history and rationale.I'll second what Alex says about the implementation burden being high to do misalignment support in userspace software. I would suspect the "easier" approach to actually be to explode every load/store into byte-size pieces, as that would be localized to just the instruction lowerings. That would have pretty severe performance cost, but maybe not as bad as using Pulley (you'd have to experiment to know for sure). I don't think we'd upstream such a patch though.
Wasmtime GitHub notifications bot (Feb 09 2026 at 10:37):tage64 closed issue #12502:
I am ahead-of-time compiling wasm for RISC-V64 using Cranelift. The generated assembly performs a 64-bit load on a 4 B (not 8 B) aligned address. This is not allowed by the RISC-V spec although many processors does support it anyway. However our RISC-V implementation (NOEL-V) don't support misaligned memory accesses.
Would it be possible for Cranelift or Wasmtime to replace misaligned memory accesses with manual load/store/shift instructions to allow ahead-of-time compilation on these platforms as well?
It runs perfectly under Pulley but is ~15x slower compared to native speed.
Wasmtime GitHub notifications bot (Feb 09 2026 at 10:37):tage64 commented on issue #12502:
Thanks for the explonation.
Last updated: Feb 24 2026 at 04:36 UTC