afonso360 opened PR #8650 from afonso360:fuzz-stackslot-alignment
to bytecodealliance:main
:
:wave: Hey,
This PR is a follow up to #8635. It adds the bare minimum possible for the Cranelift Fuzzgen to start fuzzing with different stack slot alignments.
Now that we can specify alignments, we should be able to start fuzzing load sinking with stack addresses :tada: . That isn't done yet, but this is the first step.
afonso360 requested elliottt for a review on PR #8650.
afonso360 requested wasmtime-compiler-reviewers for a review on PR #8650.
bjorn3 created PR review comment:
Currently the max working alignment is 2^4 (16 bytes): https://github.com/bytecodealliance/wasmtime/pull/8635#discussion_r1603954465
bjorn3 submitted PR review.
afonso360 submitted PR review.
afonso360 created PR review comment:
:+1: I've been following that thread. We currently don't depend on any alignment larger than 8 bytes. And at most we'll need 16bytes (for sinking SIMD loads).
But I think it's still a good idea to test with larger values, even if we end up not having any guarantee past 16 bytes.
afonso360 edited PR review comment.
bjorn3 submitted PR review.
bjorn3 created PR review comment:
I missed that you are not actually checking that the stack slot is correctly aligned at runtime.
elliottt submitted PR review:
This looks good to me! Do you have a plan for verifying alignment in the future?
afonso360 commented on PR #8650:
Yes, but hopefully we shouldn't need to.
The plan is to rely on the ABI alignment and generate loads/stores with the aligned flag if both the slot and the ABI support that alignment. That should allow us to start testing load sinking.
Now, I do plan on validating if these memory accesses are actually aligned with the interpreter. The interpreter already checks if stack accesses are aligned, when they contain the
aligned
memflag, but it currently doesn't support aligning the stack slots. Or align the stack at thecall
boundary. So those are the two missing items.This hopefully shouldn't be needed since, if we're failing fuzz runs in the interpreter its not great for fuzzing efficiency.
afonso360 merged PR #8650.
Last updated: Dec 23 2024 at 12:05 UTC