Fuzzer: Separate arguments used to make the fuzz wasm from the opts we run on it #6357
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before
FUZZ_OPTS
was used both when doing--translate-to-fuzz/-ttf
to generate thewasm from the random bytes and also when later running optimizations to generate
a second wasm file for comparison. That is, we ended up doing this, if the opts were
-O3
:Now we have a pair
a.wasm,b.wasm
which we can test. However, we have run-O3
on both which is a little silly - the second
-O3
might not actually have anything leftto do, which would mean we compare the same wasm to itself.
Worse, this is incorrect, as there are things we need to do only during the
generation phase, like
--denan
. We need that in order to generate a valid wasm totest on, but it is "destructive" in itself: when removing NaNs (to avoid nondeterminism)
if replaces them with
0
, which is different. As a result, running--denan
whengenerating the second wasm from the first could lead to different execution in them.
This was always a problem, but became more noticable recently now that DeNaN
modifies SIMD operations, as one optimization we do is to replace a
memory.copy
with
v128.load + v128.store
, and--denan
will make sure the loaded value has noNaNs...
To fix this, separate the generation and optimization phase. Instead of
(note how
--denan -O3
appears twice), do this:(note how
--denan
appears in generation, and-O3
in optimization.