Nick Fitzgerald
Nick Fitzgerald
> thought: should we be including this? fuzzing is usually run with debug assertions on so the debug_assert doesn't get us much. I am comfortable with more thoroughly documenting the...
Talking with some folks who would like to pass around an `Unstructured` through Cranelift to implement a "chaos mode" that does semantics-preserving random mutations like shuffle basic blocks, but don't...
When debugging some fiddly wasm bits I often annotate the WAT disassembly with the types on the stack in between each instruction: ```wat ;; [] i32.const 32 ;; [i32] i32.const...
Will help a lot when we start getting Wasm GC fuzz bugs.
Right now we just skip generating a `#[test]` for any test file that we don't support yet for whatever reason. But this means that if we add support for something...
This would allow us to test that the reference values we expect to appear in various stack maps at various instructions actually do show up.
Would be useful when debugging GC bugs and trying to determine whether things that are still live are actually included in the stack maps for various safepoints.
Ideas from a brainstorming session with some Cranelift folks: * [x] Typed funcrefs can statically remove null checks and sig checks; but how do we use? * In `cranelift-wasm`, need...
Apparently on ARM (edit: and riscv) when * a store is unaligned * and crosses a page boundary * and one page faults but the other doesn't then there is...
In [the general case](https://github.com/bytecodealliance/wasmtime/blob/6c5184809db3a92de4ee0c718c403bedc9a9ff4f/cranelift/wasm/src/code_translator/bounds_checks.rs#L258-L262), we do a bunch of `uadd_overflow_trap`s, but we shouldn't need to worry about overflow for 32-bit Wasm memories on 64-bit targets.