fuzzgen: Add support for stack slot alignment #8650
Conversation
github-actions
bot
added
the
cranelift
| @@ -86,6 +88,7 @@ impl Default for Config { | |||
| switch_max_range_size: 2..=32, | |||
| static_stack_slots_per_function: 0..=8, | |||
| static_stack_slot_size: 0..=128, | |||
| stack_slot_alignment_log2: 0..=10, | |||
There was a problem hiding this comment.
Currently the max working alignment is 2^4 (16 bytes): #8635 (comment)
There was a problem hiding this comment.
馃憤 I've been following that thread. We currently don't depend on any alignment. 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.
There was a problem hiding this comment.
I missed that you are not actually checking that the stack slot is correctly aligned at runtime.
|
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 This hopefully shouldn't be needed since, if we're failing fuzz runs in the interpreter its not great for fuzzing efficiency. |
馃憢 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 馃帀 . That isn't done yet, but this is the first step.