summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Remove `constexpr` that causes GCC build to fail (#2828)Thomas Lively2020-05-041-1/+1
| | | | | | | GCC complains that the enclosing class of the constexpr member function is not a literal type. This change removes the constexpr qualifier to fix the GCC build. Fixes #2827.
* CI: Use stripped release builds for distribution (#2826)Sam Clegg2020-05-042-10/+30
| | | | | | | | | | | Even though `Release` is the default configuration for make better to be explicit. Also, for windows build we need to make sure we pass `--config Release` when actually building since the projects files will build Debug by default regardless of CMAKE_BUILD_TYPE. Fixes: #2825
* Final renumbering of SIMD opcodes (#2820)Thomas Lively2020-05-012-188/+203
| | | As described in https://github.com/WebAssembly/simd/pull/209.
* Add stack-pointer argument to post-emscripten pass. (#2823)Sam Clegg2020-05-015-7/+37
| | | | | | | This allows emscripten to statically set the initial value of the stack pointer. Should allow use to avoid doing it dynamically at startup: https://github.com/emscripten-core/emscripten/pull/11031
* fuzz_opt.py improvements (#2822)Alon Zakai2020-04-301-31/+41
| | | | | | | | | | | | | | Don't run wasm2c2wasm on large wasm files, as it can OOM the VM. I've seen this happen on a single wasm on multiple engines, so it's not a specific engine bug. Sticking to below-average wasm sizes seems ok. That change means that we check if a vm can run on a per-wasm basis. That required some refactoring as it means we may be able to run on the "before" wasm but not the "after" one, or vice versa. Fix a tiny nondeterminism issue with iterating on a set(). Some tiny docs improvements to the error shown when a bug is found.
* Stop generating implementedFunctions in wasm-emscripten-finalize (#2819)Sam Clegg2020-04-2833-260/+0
| | | | This list is identical to the export list no there is no need to output this twice.
* Simple reduction for any* fuzzer-found bug (#2817)Alon Zakai2020-04-281-131/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds on recent work for deterministic reproduction of fuzzer testcases using IDs. With that, we can remove all the old auto-reduction code and make something very similar possible for all* things the fuzzer script checks for. The idea is simple: if you run the fuzzer script and it finds a bug, it prints out the ID it found it with. If you then run fuzz_opt.py ID then it runs that exact testcase again, deterministically, making all the same random choices it made before. The new addition in this PR is that you can do fuzz_opt.py ID WASM which also adds a wasm file. If provided, we still randomly generate one in the fuzzer script (so that later random numbers are the same) but we swap in that provided wasm. This then lets wasm-reduce drive fuzz_opt.py itself as a whole. No more extracting a testcase and all its commands, it's all done for you. The fuzzer script will print out hopefully-useful text when it finds a bug, something like this: ================================================================================ You found a bug! Please report it with seed: 4671273171120144526 and the exact version of Binaryen you found it on, plus the exact Python version (hopefully deterministic random numbers will be identical). You can run that testcase again with "fuzz_opt.py 4671273171120144526" The initial wasm file used here is saved as /home/username/binaryen/out/test/original.wasm You can try to reduce the testcase with wasm-reduce /home/username/binaryen/out/test/original.wasm '--command=bash reduce.sh' -t /home/username/binaryen/out/test/t.wasm -w /home/username/binaryen/out/test/w.wasm where "reduce.sh" is something like # check the input is even a valid wasm file bin/wasm-opt /home/username/binaryen/out/test/t.wasm echo $? # run the command ./scripts/fuzz_opt.py 4671273171120144526 /home/username/binaryen/out/test/t.wasm > o 2> e cat o | tail -n 10 echo $? You may want to adjust what is printed there: in the example we save stdout and stderr separately and then print (so that wasm-reduce can see it) what we think is the relevant part of that output. Make sure that includes the right details, and preferably no more (less details allow more reduction, but raise the risk of it reducing to something you don't quite want). You may also need to add --timeout 5 or such if the testcase is a slow one. ================================================================================ The text has full instructions to run the reducer, which should work in almost all cases - see (*) note below. Because of that corner case I think it's safer to not run the reducer automatically, but it's just a quick copy-paste away, and the user can then adjust the reduce.sh script if necessary. (*) Well, almost any. There are some corner cases, such as if the fuzzer generator includes bounds checks in the wasm, reduction might remove them. We can fix this eventually by making the bounds checks additions a pass that can be run after the fuzzer generator, but meanwhile you can work around this by making the reduction script look for the right thing (i.e. if all it looks for is a failing return code, that won't be enough as a removed bounds check will fail but on something else).
* Fix wasm2c loop (#2816)Alon Zakai2020-04-281-5/+6
| | | | | | The refactoring of the loop in #2812 was wrong - we need to loop over all the exports and ignore the non-function ones. Rewrote it to stress that part.
* Remove wasm2c2wasm can_compare_self (#2814)Alon Zakai2020-04-281-3/+0
| | | | | Just like the parent wasm2c, with NaNs don't compare to self before and after optimizations. The binaryen optimizer does different things than the LLVM optimizer there, and NaN bits can change.
* Use --detect-features in wasm-reduce. Fixes #2813 (#2815)Alon Zakai2020-04-282-9/+5
|
* Refactor ExpressionRunner (#2804)Daniel Wirtz2020-04-273-138/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tackles the concerns raised in https://github.com/WebAssembly/binaryen/issues/2797 directly related to https://github.com/WebAssembly/binaryen/pull/2702 by reverting merging all of `PrecomputeExpressionRunner` into the base `ExpressionRunner`, instead adding a common base for both the precompute pass and the new C-API to inherit. No functional changes. --- ### Current hierarchy after https://github.com/WebAssembly/binaryen/pull/2702 is ``` ExpressionRunner ├ [PrecomputeExpressionRunner] ├ [CExpressionRunner] ├ ConstantExpressionRunner └ RuntimeExpressionRunner ``` where `ExpressionRunner` contains functionality not utilized by `ConstantExpressionRunner` and `RuntimeExpressionRunner`. ### New hierarchy will be: ``` ExpressionRunner ├ ConstantExpressionRunner │ ├ [PrecomputeExpressionRunner] │ └ [CExpressionRunner] ├ InitializerExpressionRunner └ RuntimeExpressionRunner ``` with the precompute pass's and the C-API's shared functionality now moved out of `ExpressionRunner` into a new `ConstantExpressionRunner`. Also renames the previous `ConstantExpressionRunner` to `InitializerExpressionRunner` to [better represent its uses](https://webassembly.org/docs/modules/#initializer-expression) and to make its previous name usable for the new intermediate template, where it fits perfectly. Also adds a few comments answering some of the questions that came up recently. ### Old hierarchy before https://github.com/WebAssembly/binaryen/pull/2702 for comparison: ``` ExpressionRunner ├ [PrecomputeExpressionRunner] ├ ConstantExpressionRunner └ RuntimeExpressionRunner ```
* Emcc fuzzing followups (#2812)Alon Zakai2020-04-272-5/+20
| | | | | | Avoid pass-debug when fuzzing emcc, as it can be slow and isn't what we care about. Clean up a loop.
* Version 93 (#2800)Sam Clegg2020-04-272-1/+7
|
* Fix binaryenjs testing (#2810)Sam Clegg2020-04-274-11/+26
| | | | | | These tests are now optional. However, if you run them and the build is not found they will now error out, in order to avoid silently failing.
* Fuzz frequency tuning (#2806)Alon Zakai2020-04-276-1805/+1354
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove --fuzz-binary and simplify round trip (#2799)Thomas Lively2020-04-247-84/+74
| | | Since the --roundtrip pass is more general than --fuzz-binary anyways. Also reimplements `ModuleUtils::clearModule` to use the module destructor and placement new to ensure that no members are missed.
* Wasm2c2Wasm Fuzzer: wasm2c + emcc (#2791)Alon Zakai2020-04-242-16/+67
| | | | | | | | | This adds a variant on wasm2c that uses emcc instead of a native compiler. This helps us fuzz emcc. To make that practical, rewrite the setjmp glue to only use one setjmp. The wasm backend ends up doing linear work per setjmp, so it's quadratic with many setjmps. Instead, do a big switch-loop construct around a single setjmp.
* Fix RemoveUnusedNames on a loop with no name and a child with a different ↵Alon Zakai2020-04-243-1/+17
| | | | type. fixes #2807 (#2808)
* CI: Trigger on pull_request (#2801)Sam Clegg2020-04-241-1/+6
|
* Emit section IDs as bytes (#2803)Thomas Lively2020-04-241-4/+4
| | | As described in the spec.
* CI: Use alpine linux when building official linux releases (#2796)Sam Clegg2020-04-232-37/+63
| | | | | The alpine linux build exists to produce portable binaries. It should be used when building release assets, rather than during CI.
* Trigger CI on all branch pushes even before PR is opened. (#2793)Sam Clegg2020-04-231-4/+1
|
* Fix ExpressionRunner issues found by the fuzzer (#2790)Daniel Wirtz2020-04-233-17/+22
| | | | | | | Fixes #2788 found by the fuzzer, introduced in #2702, which turned out to be incorrect usage of std::move, by removing any std::moves introduced in that PR to be better safe than sorry. Also fixes problems with WASM_INTERPRETER_DEBUG spotted during debugging.
* Add snake_case method names for returnCall/returnCallIndirect in JS API (#2795)Shao Cheng2020-04-233-7/+10
|
* Emit text in pass reduction when in text mode (#2792)Alon Zakai2020-04-221-0/+3
| | | | | | | Without this we emitted a binary, which confused the size comparisons. (When reducing a smaller size is usually a good sign. And also it provides a deterministic way to know when to stop - we can't infinite loop if we keep going while the size shrinks.)
* CI: Avoid downloading cmake unnecessarily (#2789)Sam Clegg2020-04-221-6/+1
| | | Also fix typo
* [fuzzing] wasm2c integration (#2772)Alon Zakai2020-04-224-63/+323
| | | | | | | | | | | | | | | | | | | | | | | | | This adds support for fuzzing with wabt's wasm2c that @binji wrote. Basically we compile the wasm to C, then compile the C to a native executable with a custom main() to wrap around it. The executable should then print exactly the same as that wasm when run in either the binaryen interpreter or in a JS VM with our wrapper JS for that wasm. In other words, compiling the wasm to C is another way to run that wasm. The main reasons I want this are to fuzz wasm2c itself, and to have another option for fuzzing emcc. For the latter, we do fuzz wasm-opt quite a lot, but that doesn't fuzz the non-wasm-opt parts of emcc. And using wasm2c for that is nice since the starting point is always a wasm file, which means we can use tools like wasm-reduce and so forth, which can be integrated with this fuzzer. This also: Refactors the fuzzer harness a little to make it easier to add more "VMs" to run wasms in. Do not autoreduce when re-running a testcase, which I hit while developing this.
* Add BinaryenCallIsReturn/BinaryenCallIndirectIsReturn to C/JS API (#2779)Shao Cheng2020-04-225-0/+62
|
* CI: Fix windows asset upload (#2785)Sam Clegg2020-04-211-9/+31
| | | Also add upload of shasum file
* Also update internal name in fixEmJsFuncsAndReturnWalker (#2782)Sam Clegg2020-04-213-26/+30
| | | | | | Without this change only the import gets renamed not the internal name. Since the internal name is the one that ends up in the name section this means that rename wasn't effecting the name section.
* CI: clang-tidy requires cmake to have been run (#2783)Sam Clegg2020-04-211-19/+8
| | | | | | I somehow missed this the transition to github actions. Also the I forgot to include the gen-s-parser test.
* Convert CI from travis + appveyor to github actions (#2646)Sam Clegg2020-04-217-254/+321
| | | | | | The intention is to move away from travis and appveyor which have become very slow. See: #2356
* Refactor expression runner so it can be used via the C and JS APIs (#2702)Daniel Wirtz2020-04-2016-103/+882
| | | | | | | Refactors most of the precompute pass's expression runner into its base class so it can also be used via the C and JS APIs. Also adds the option to populate the runner with known constant local and global values upfront, and remembers assigned intermediate values as well as traversing into functions if requested.
* Version 92 (#2778)Sam Clegg2020-04-202-1/+14
|
* Remove non-x86_64 architectures build from our travis config (#2777)Sam Clegg2020-04-171-17/+0
| | | | | | | | | | | | | | | These have not been working since #1554, where we switch to using an alpine docker image rather than the alpine sysroot install script (that honors the ARCH environment variable). So nobody has noticed in the last 2 years that we've been releasing copies of x86_64 binaries. e.g: this file actually contains x86_64 binaries: https://github.com/WebAssembly/binaryen/releases/download/version_91/binaryen-version_91-aarch64-linux.tar.gz What is more its not really our job to release binaries for all these different architectures. We can let downstream distos do that. Node itself doesn't ship 32bit x86 linux images.
* Fix issues with Types and Features (#2773)Thomas Lively2020-04-163-4/+8
| | | | | | | | | 1. Only emit exnref as part of a subtype if exception-handling is enabled in the fuzzer. 2. Correctly report that funcref and nullref require reference-types to be enabled. 3. Re-enable multivalue as a normal feature in the fuzzer. Possibly fixes #2770.
* Report errors in scripts/clang-tidy-diff.sh if clang-tidy is not found (#2775)Sam Clegg2020-04-161-3/+12
|
* Dummy interpreter support for EH (#2774)Heejin Ahn2020-04-162-21/+76
| | | | | | | | | | | | | | | | | | | | | | This adds dummy interpreter support for EH instructions, mainly for fuzzing. The plan is to make the interpreter support for EH instructions correctly using Asyncify in the future. Also to support the correct behavior we will need a `Literal` of `exnref` type too, which will be added later too. Currently what this dummy implementation does is: - `try`-`catch`-`end`: only runs `try` body and ignores `catch` body - `throw`: traps - `retyrow`: - Traps on nullref argument (correct behavior based on the spec) - Traps otherwise too (dummy implementation for now) - `br_on_exn`: - Traps on nullref (correct behavior) - Otherwise we assume the current expression matches the current event and extracts a 0 literal based on the current type. This also adds some interpreter tests, which tests the basic dummy behaviors for now. (Deleted tests are the ones that weren't tested before.)
* Disable multivalue in fuzzer in a clearer way (#2771)Alon Zakai2020-04-161-7/+3
|
* Validate that tuples have multiple operands (#2768)Thomas Lively2020-04-161-0/+2
| | | This was previously an unwritten and unchecked assumption.
* Fix OOB fuzzing (#2769)Alon Zakai2020-04-161-9/+15
| | | | | | | | | We should only do weird changes to the fuzz code if we allow out of bounds operations, because the OOB checks are generated as we build the IR, and changing them can remove the checks. (we fuzz 50% of the time with and 50% without OOBs, so this doesn't really hurt us)
* Emit tuples in the fuzzer (#2695)Thomas Lively2020-04-155-860/+1540
| | | | | | | | Emit tuple.make, tuple.extract, and multivalue control flow, and tuple locals and globals when multivalue is enabled. Also slightly refactors the top-level `makeConcrete` function to be more selective about what it tries to make based on the requested type to reduce the number of trivial nodes created because the requested type is incompatible with the requested node.
* Enable cross-VM fuzzing + related improvements to fuzz_opt.py (#2762)Alon Zakai2020-04-154-109/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main benefit here is comparing VMs, instead of just comparing each VM to itself after opts. Comparing VMs is a little tricky since there is room for nondeterminism with how results are printed and other annoying things, which is why that didn't work well earlier. With this PR I can run 10's of thousands of iterations without finding any issues between v8 and the binaryen interpreter. That's after fixing the various issues over the last few days as found by this: #2760 #2757 #2750 #2752 Aside from that main benefit I ended up adding more improvements to make it practical to do all that testing: Randomize global fuzz settings like whether we allow NaNs and out-of-bounds memory accesses. (This was necessary here since we have to disable cross-VM comparisons if NaNs are enabled.) Better logging of statistics like how many times each handler was run. Remove redundant FuzzExecImmediately handler (looks like after past refactorings it was no longer adding any value). Deterministic testcase handling: if you run e.g. fuzz_opt.py 42 it will run one testcase and exactly the same one. If you run without an argument it will run forever until it fails, and if it fails, it prints out that ID so that you can easily reproduce it (I guess, on the same binaryen + same python, not sure how python's deterministic RNG changes between versions and builds). Upgrade to Python 3.
* Fix reuse of constant nodes in Precompute (#2764)Heejin Ahn2020-04-143-28/+156
| | | | | | | | | | Previously we tried to reuse `Const` node if a precomputed value is a constant node. But now we have two more kinds of constant node (`RefNull` and `RefFunc`), so we shouldn't reuse them interchangeably, meaning we shouldn't try to reuse a `Const` node when the value at hand is a `RefNull`. This correctly checks the type of node and tries to reuse only if the types of nodes match. Fixes #2759.
* Note removal of catch body in Vacuum (#2765)Heejin Ahn2020-04-143-0/+19
| | | | | | When it is certain that the try body does not throw, we can replace the try-catch with the try body. But in this case we have to notify the type updater that the catch body is removed, so that all parents' type should be updated properly.
* Fix build with a sprinkling of braces (#2766)Thomas Lively2020-04-141-11/+11
|
* Fix auto updater on spec tests after #2755 (#2763)Alon Zakai2020-04-131-0/+4
|
* Fix Atomics fuzz bugs in interpreter (#2760)Alon Zakai2020-04-135-114/+423
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am working to bring up the fuzzer on comparisons between VMs. Comparing between the binaryen interpreter and v8, it found some atomics issues: Atomic operations, including loads and stores, must be aligned or they trap. AtomicRMW did the wrong thing with the operands. AtomicCmpxchg must wrap the input to the proper size (if we only load 1 byte, only look at 1 byte of the expected value too). AtomicWait and AtomicNotify must take into account their offsets. Also SIMDLoadExtend was missing that. This was confusing in the code as two getFinalAddresses existed, one that doesn't compute with an offset, and one that does. I renamed the one without to getFinalAddressWithoutOffset so it's explicit and we can easily see we only call that one on an instruction without an offset (which is the case for MemoryInit, MemoryCopy, and MemoryFill). AtomicNotify must check its address to see if it should trap, even though we don't actually have multiple threads running. Atomic loads of fewer bytes than the type always do an unsigned extension, not signed.
* Use direct pointers as Type IDs (#2745)Thomas Lively2020-04-1312-375/+427
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using indices into the global interned type table. This means that a lock is *never* needed to access an expanded Type. The Type lock is now only acquired when a complex Type is created. On a real-world wasm2js workload this improves wall clock time by 23% on my machine with 72 cores and makes traffic on the Type lock entirely insignificant. **Before** 72 cores real 0m6.914s user 184.014s sys 0m3.995s 1 core real 0m25.903s user 0m25.658s sys 0m0.253s **After** 72 cores real 5.349s user 70.309s sys 9.691s 1 core real 25.859s user 25.615s sys 0.253s
* Update v8 flags (#2754)Alon Zakai2020-04-131-5/+3
|