diff options
author | Alon Zakai <azakai@google.com> | 2020-04-27 09:07:23 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-04-27 09:07:23 -0700 |
commit | 25c884e6b91e25e87a4fd6298bf511d17737b112 (patch) | |
tree | 6ec3bce12ca43f57980bac3c06dc781d6966421d /auto_update_tests.py | |
parent | 12445969dc5b32cbe82b829fe8c061f5d98fcbe7 (diff) | |
download | binaryen-25c884e6b91e25e87a4fd6298bf511d17737b112.tar.gz binaryen-25c884e6b91e25e87a4fd6298bf511d17737b112.tar.bz2 binaryen-25c884e6b91e25e87a4fd6298bf511d17737b112.zip |
Fuzz frequency tuning (#2806)
We had some ad-hoc tuning of which nodes to emit more
frequently in the fuzzer, but it wasn't very good. Things like
loads and stores for example were far too rare. Also it wasn't
easy to adjust the frequencies.
This adds a simple way to adjust them, by passing a size_t
which is the "weight" of that node. Then it just makes that
number of copies of it, making it more likely to be picked.
Example output comparison:
node before after
================================
binary 281 365
block 898 649
break 278 144
call 182 290
call_indirect 9 42
const 808 854
drop 43 92
global.get 440 398
global.set 223 171
if 335 254
load 22 84
local.get 429 301
local.set 434 211
loop 176 99
nop 117 54
return 264 197
select 8 33
store 1 39
unary 405 304
unreachable 1 2
Lots of noise here obviously, but there are large increases
for loads and stores compared to before.
Also add a testcase of random data of the typical size the
fuzzer runs, and print metrics on it. This might help us get
a feel for how future tuning changes affect frequencies.
Diffstat (limited to 'auto_update_tests.py')
0 files changed, 0 insertions, 0 deletions