summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* Added headers to CMake files (#3037)Wouter van Oortmerssen2020-08-107-0/+14
| | | This is needed for headers to show up in IDE projects, and has no other effect on the build.
* Fix typo in Asyncify comment (#3031)Nikita Baksalyar2020-08-101-1/+1
|
* DWARF: Fix debug_info references to the abbreviations section (#2997)Alon Zakai2020-08-076-7/+29
| | | | | | | | | | | | | | | | The previous code assumed that each compile unit had its own abbreviation section, and they are all in order. That's normally how LLVM emits things, but in #2992 there is a testcase in which linking of object files with IR files somehow ends up with a different order. The proper fix is to track the binary offsets of abbreviations in the abbreviation section. That section is comprised of null-terminated lists, which each CU has an offset to the beginning of. With those offsets, we can match things properly. Add a testcase that crashes without this, to prevent regressions. Fixes #2992 Fixes #3007
* Fuzzing: Compare wasm2js to the interpreter (#3026)Alon Zakai2020-08-061-14/+76
| | | | | | | | | | | | | | | | Comparing to the interpreter, and not just wasm2js to itself (which we've done on the same file before and after opts) ensures wasm2js has the right semantics. To do this, we need to make sure the wasm doesn't contain things where wasm2js semantics diverge from normal wasm, which includes: * Legalize so that there are no i64 exports. * Remove operations JS can't handle with full precision, like i64 -> f32. * Force all loads/stores to be 1-byte, as unexpectedly-unaligned operations fail in wasm2js. This also requires ignoring subnormals when comparing between JS VMs and the interpreter.
* StubUnsupportedJSOps: Remove CallIndirects (#3027)Alon Zakai2020-08-063-6/+70
| | | | | | wasm2js does not have full call_indirect support as we don't trap if the type is incorrect, which wasm does. Therefore the StubUnsupportedJSOps pass needs to remove those operations so that the fuzzer doesn't find spurious issues.
* Fix CountLeadingZeroes on MSVC (#3028)Alon Zakai2020-08-061-2/+5
| | | | | | | We just had the logic there wrong - MSVC's intrinsic returns the bit index, not the number of leading zeros. That's identical when scanning forward but not in reverse... Fixes #2942
* Asyncify verbose option (#3022)Alon Zakai2020-08-065-11/+430
| | | | | | | | | | | | | | | | This logs out the decisions made about instrumenting functions, which can help figure out why a function is instrumented, or to get a list of what might need to be. As the test shows, it can print things like this: [asyncify] import is an import that can change the state [asyncify] calls-import can change the state due to import [asyncify] calls-calls-import can change the state due to calls-import [asyncify] calls-calls-calls-import can change the state due to calls-calls-import (the test has calls-calls-calls-import => calls-calls-import => calls-import -> import).
* Refactor wasm-emscripten-finalize to use a single pass runner (#2987)Sam Clegg2020-08-0511-124/+118
|
* Add StubUnsupportedJSOps to remove operations that JS does not support (#3024)Alon Zakai2020-08-056-1/+120
| | | | | | | | This doesn't lower them - it just replaces the unsupported operation with a drop. This will be useful for fuzzing, where to compare JS to the correct semantics we must avoid operations where JS is not always accurate. Also fully document the i64 -> f32 conversion issue in JS.
* Adjust fuzzing frequencies (#3021)Alon Zakai2020-08-041-3/+9
|
* Move generateDynCallThunks into its own pass. NFC. (#3000)Sam Clegg2020-08-049-18/+99
| | | | | | The core logic is still living in EmscriptenGlueGenerator because its used also by fixInvokeFunctionNames. As a followup we can figure out how to make these more independent.
* Refactor getMaxBits() out of OptimizeInstructions and add beginnings of unit ↵Alon Zakai2020-08-043-223/+265
| | | | | | | | | testing for it (#3019) getMaxBits just moves around, no logic is changed. Aside from adding getMaxBits, the change in bits.h is 99% whitespace. helps #2879
* Modernize binaryen.js glue code (#3005)Max Graey2020-08-041-1142/+1032
|
* Implement prototype v128.load{32,64}_zero instructions (#3011)Thomas Lively2020-08-0318-11/+126
| | | | | | | | Specified in https://github.com/WebAssembly/simd/pull/237. Since these are just prototypes necessary for benchmarking, this PR does not add support for these instructions to the fuzzer or the C or JS APIs. This PR also renumbers the QFMA instructions that previously used the opcodes for these new instructions. The renumbering matches the renumbering in V8 and LLVM.
* Use consistent backquotes instead ordinal quotes for Grain in README (#3017)Max Graey2020-08-031-1/+1
|
* AlignmentLowering: Handle all possible cases for i64, f32, f64 (#3008)Alon Zakai2020-07-313-27/+1613
| | | | | | | | | | Previously we only handled i32. That was enough for all real-world code people have run through wasm2js apparently (which is the only place the pass is needed - it lowers unaligned loads to individual loads etc., as unaligned operations fail in JS). Apparently it's pretty rare to have unaligned f32 loads for example. This will be useful in fuzzing wasm2js, as without this we can't compare results to the interpreter (which does alignment properly).
* New Dealign pass: reduce load/store alignment to 1 (#3010)Alon Zakai2020-07-316-0/+90
| | | | | Pretty trivial, but will be useful in wasm2js testing, where we can't assume an incorrectly-aligned load/store will still work, so we'll need to be pessimistic about alignment there.
* Specify UTF-8 encoding instead of relying on locale default (#3009)rathann2020-07-311-1/+1
| | | | Current locale may not be UTF-8, which makes the spec/names.wast test fail. Fixes issue #3003.
* Better const fuzzing (#2972)Alon Zakai2020-07-303-419/+376
| | | | | | | | Tweak floating-point numbers with not just a +-1 integer, but also a float in [-1, 1]. Apply a tweak to powers of 2 as well. This found bugs in various codebases, see WebAssembly/spec#1224
* wasm2js: Add an "Export" scope for name resolution (#2998)Alon Zakai2020-07-303-67/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we used "Top" for both exports and the top level (which has functions and globals). The warning about name collisions there was meant only for exports (where if a name collides and so it must be renamed, means that there will be an externally-visible oddness for the user). But it applied to functions too, which could be annoying, and was not dangerous (at worst, it might be confusing when reading the emitted JS and seeing NAME_1, NAME_2, but there is no effect on execution or on exports). To fix this, add a new Export name scope. This separates function names from export names. However, it runs into another issue which is that when checking for a name conflict we had a big set of all the names in all the scopes. That is, FOO would only ever be used in one scope, period, and other appearances of that Name in wasm would get a suffix. As a result, if an exported function FOO has the name foo, we'd export it as FOO but name the function FOO_1 which is annoying. To fix that, keep sets of all names in each scope. When mangling a name we can then only care about the relevant scope, EXCEPT for local names, which must also not conflict with function names. That is, this would be bad: function foo(bar) { var bar = 0; } function bar() { .. It's not ok to call a parameter "bar" if there is a function by that name (well, it could be if it isn't called in that scope). So when mangling the Local scope, also check the Top one as well. The test output changes are due to non-overlapping scopes, specifically Local and Label. It's fine to have foo : while(1) { var foo = 5; } Those "foo"s do not conflict. Fixes emscripten-core/emscripten#11743
* Fix build for win32 (#3001)Max Graey2020-07-291-2/+2
| | | | | Check for x64 before using a non-32bit operation. See #2955 for context.
* wasm2js: Remove an incorrect optimization (#3004)Alon Zakai2020-07-292-8/+3
| | | | optimizeBoolean does not receive a boolean, it is done when the output flows into a boolean context.
* binaryen.js: use ECMASCRIPT6 for Closure Compiler (#2990)Max Graey2020-07-291-1/+3
|
* Remove dynCall generated from fpcast-emu (#2995)Sam Clegg2020-07-282-190/+1
| | | | | | | | This is precursor to moving dynCall generation into a pass of its own. It seems to be up to the caller if they want to run dynCall generation either before or after fpcast-emu. Verified that this change does not effect emscripten's wasm2 other other test suite.
* AvoidReinterprets should not remove code around a reinterpret's value's ↵Alon Zakai2020-07-283-3/+36
| | | | | | | | | | | | | | | | | fallthrough (#2989) We can turn a reinterpret of a load into a different load, and so forth, but if the reinterpret has a non-load child with a load fallthrough, that's not good enough - we can't remove the extra code: (reinterpret (block ..extra code.. (load) ) ) That can't be turned into a load of the flipped type.
* Fix the side effects of data.drop (#2996)Alon Zakai2020-07-284-8/+51
| | | | | | | | | | | | | We marked it as readsMemory so that it could be reordered with various things, except for memory.init. However, the fuzzer found that's not quite right, as it has a global side effect - memory.inits that run later can notice that. So it can't be reordered with anything that might affect global side effects from happening, as in the testcase added here (an instruction that may trap cannot be reordered with a data.drop, as it may prevent the data.drop from happening and changing global state). There may be a way to optimize this more carefully that would allow more optimizations, but as this is a rare instruction I'm not sure it's worth more work.
* wasm2js: Don't remove an | 0 or >>> 0 in a boolean context (#2993)Alon Zakai2020-07-283-24/+34
| | | | | | | | | | | | | It is usually fine to do if (x | 0) => if (x) since it just cares if the value is 0 or not. However, if the cast turns it into 0, then that is incorrect, which the fuzzer found as -2147483648 + -2147483648 | 0 (the sum is 2^32, which | 0 is 0). We can maybe look into doing this in a safe way, but for now just remove it. It doesn't have a big impact on code size as this is pretty rare (e.g. the minimal runtime code size test is not broken by this).
* Move stack-check into its own pass (#2994)Sam Clegg2020-07-278-119/+172
| | | | | This new pass takes an optional stack-check-handler argument which is the name of the function to call on stack overflow. If no argument is passed then it just traps.
* Some minor improvements for binaryen.js epilogue (#2947)Max Graey2020-07-271-45/+35
| | | Simplify stack allocation and array generation logic.
* wasm-emscripten-finalize: remove exportWasiStart (#2986)Sam Clegg2020-07-276-66/+4
| | | | This should not be needed since in emscripten standalone mode we always include a crt1.o that includes _start.
* Move emscripten PIC ABI conversion to a pass. NFC. (#2985)Sam Clegg2020-07-2420-228/+290
| | | | Doing it this way happens to re-order the __assign_got_entries function in the module, but its otherwise NFC.
* Move ReplaceStackPoint into a pass (#2984)Sam Clegg2020-07-247-62/+112
| | | First step in making wasm-emscripten-finalize use more passes.
* Update flags used in generate_lld_tests (#2981)Sam Clegg2020-07-241-1/+1
| | | | | | | | | | | | The `--no-gc-sections` was added as part of #2857 but is not needed and in fact changes the output of some tests. `--experimental-pic` is needed these days when building shared libraries with emscripten's abi. After these two changes I verfied that the following command generated no local changes (i.e. is a no-op): ./scripts/test/generate_lld_tests.py --binaryen-bin=$PWD/../binaryen-out/bin/ $PWD/../llvm-build/bin/ $PWD/../emscripten
* Wasm2c fuzz support: only emit a call to the hang limit function if present ↵Alon Zakai2020-07-243-2/+28
| | | | | (#2977) It may not be present while reducing a testcase, if the reducer removed it.
* wasm2js fuzzing: properly ignore trapping code (#2980)Alon Zakai2020-07-241-12/+31
| | | | | | | | | | | | | | | | | | | wasm2js fuzzing should not compare outputs if the wasm would trap. wasm2js traps on far fewer things, and if wasm would trap (like an indirect call with the wrong type) it can just do weird undefined things. Previously, if running wasm2js trapped then we ignored the output, but that't not good enough, as we need to check if wasm would, exactly for the cases just mentioned where wasm would trap but wasm2js wouldn't. So run the wasm interpreter to see if that happens. When we see such a trap, ignore everything from that function call onwards. This at least lets us compare the results of previous calls, which adds some amount of coverage (before we just ignored the entire output completely, so only if there was no trap at all did we do any comparisons at all). Also give better names than "js.js" to the JS files wasm2js fuzzing creates.
* DWARF: Do not reorder locals in binary writing (#2959)Alon Zakai2020-07-2314-6143/+6892
| | | | | | | | | | | | | | | | | | | | | The binary writer reorders locals unconditionally. I forgot about this, and so when I made DWARF disable optimization passes that reorder, this was left active. Optimally the writer would not do this, and the ReorderLocals pass would. But it looks like we need special logic for tuple locals anyhow, as they expand into multiple locals, so some amount of local order changes seems unavoidable atm. Test changes are mostly just lots of offsets, and can be ignored, but the new test test/passes/dwarf-local-order.* shows the issue. It prints $foo once, then after a roundtrip (showing no reordering), then it strips the DWARF section and prints after another roundtrip (which does show reordering). This also makes us avoid the Stack IR writer if DWARF is present, which matches what we do with source maps. This doesn't prevent any known bugs, but it's simpler this way and debugging + Stack IR opts is not an important combination.
* wasm2js: coerce function pointer indexes (#2979)Alon Zakai2020-07-2210-18/+135
| | | | | | | | | | | | | | | | | We emit FUNCTION_TABLE[ptr], where FUNCTION_TABLE is a JS array. That is a rare case where true is handled differently than 1 (a typed array or an add would cast, etc.), so we must explicitly cast there. Fixes an issue that existed before, but became a problem due to #2869 which optimized some selects into a form that emitted a true or a false, and if that was a function pointer, it could be bad, see https://app.circleci.com/pipelines/github/emscripten-core/emscripten/6699/workflows/0c4da49c-75d0-4b0a-8fac-686a8330a3fe/jobs/336520 The new test/wasm2js/indirect-select.2asm.js.opt output shows what happened there. Verified as passing emscripten's wasm2js1 wasm2js2 test suites.
* Fix i32.trunc_f64_u of values that round down to UINT32_MAX (#2976)Alon Zakai2020-07-222-5/+18
|
* Extend the C- and JS-APIs (#2586)Daniel Wirtz2020-07-229-54/+4972
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Renames the following C-API functions BinaryenBlockGetChild to BinaryenBlockGetChildAt BinaryenSwitchGetName to BinaryenSwitchGetNameAt BinaryenCallGetOperand to BinaryenCallGetOperandAt BinaryenCallIndirectGetOperand to BinaryenCallIndirectGetOperandAt BinaryenHostGetOperand to BinaryenHostGetOperandAt BinaryenThrowGetOperand to BinaryenThrowGetOperandAt BinaryenTupleMakeGetOperand to BinaryenTupleMakeGetOperandAt Adds the following C-API functions BinaryenExpressionSetType BinaryenExpressionFinalize BinaryenBlockSetName BinaryenBlockSetChildAt BinaryenBlockAppendChild BinaryenBlockInsertChildAt BinaryenBlockRemoveChildAt BinaryenIfSetCondition BinaryenIfSetIfTrue BinaryenIfSetIfFalse BinaryenLoopSetName BinaryenLoopSetBody BinaryenBreakSetName BinaryenBreakSetCondition BinaryenBreakSetValue BinaryenSwitchSetNameAt BinaryenSwitchAppendName BinaryenSwitchInsertNameAt BinaryenSwitchRemoveNameAt BinaryenSwitchSetDefaultName BinaryenSwitchSetCondition BinaryenSwitchSetValue BinaryenCallSetTarget BinaryenCallSetOperandAt BinaryenCallAppendOperand BinaryenCallInsertOperandAt BinaryenCallRemoveOperandAt BinaryenCallSetReturn BinaryenCallIndirectSetTarget BinaryenCallIndirectSetOperandAt BinaryenCallIndirectAppendOperand BinaryenCallIndirectInsertOperandAt BinaryenCallIndirectRemoveOperandAt BinaryenCallIndirectSetReturn BinaryenCallIndirectGetParams BinaryenCallIndirectSetParams BinaryenCallIndirectGetResults BinaryenCallIndirectSetResults BinaryenLocalGetSetIndex BinaryenLocalSetSetIndex BinaryenLocalSetSetValue BinaryenGlobalGetSetName BinaryenGlobalSetSetName BinaryenGlobalSetSetValue BinaryenHostSetOp BinaryenHostSetNameOperand BinaryenHostSetOperandAt BinaryenHostAppendOperand BinaryenHostInsertOperandAt BinaryenHostRemoveOperandAt BinaryenLoadSetAtomic BinaryenLoadSetSigned BinaryenLoadSetOffset BinaryenLoadSetBytes BinaryenLoadSetAlign BinaryenLoadSetPtr BinaryenStoreSetAtomic BinaryenStoreSetBytes BinaryenStoreSetOffset BinaryenStoreSetAlign BinaryenStoreSetPtr BinaryenStoreSetValue BinaryenStoreGetValueType BinaryenStoreSetValueType BinaryenConstSetValueI32 BinaryenConstSetValueI64 BinaryenConstSetValueI64Low BinaryenConstSetValueI64High BinaryenConstSetValueF32 BinaryenConstSetValueF64 BinaryenConstSetValueV128 BinaryenUnarySetOp BinaryenUnarySetValue BinaryenBinarySetOp BinaryenBinarySetLeft BinaryenBinarySetRight BinaryenSelectSetIfTrue BinaryenSelectSetIfFalse BinaryenSelectSetCondition BinaryenDropSetValue BinaryenReturnSetValue BinaryenAtomicRMWSetOp BinaryenAtomicRMWSetBytes BinaryenAtomicRMWSetOffset BinaryenAtomicRMWSetPtr BinaryenAtomicRMWSetValue BinaryenAtomicCmpxchgSetBytes BinaryenAtomicCmpxchgSetOffset BinaryenAtomicCmpxchgSetPtr BinaryenAtomicCmpxchgSetExpected BinaryenAtomicCmpxchgSetReplacement BinaryenAtomicWaitSetPtr BinaryenAtomicWaitSetExpected BinaryenAtomicWaitSetTimeout BinaryenAtomicWaitSetExpectedType BinaryenAtomicNotifySetPtr BinaryenAtomicNotifySetNotifyCount BinaryenAtomicFenceSetOrder BinaryenSIMDExtractSetOp BinaryenSIMDExtractSetVec BinaryenSIMDExtractSetIndex BinaryenSIMDReplaceSetOp BinaryenSIMDReplaceSetVec BinaryenSIMDReplaceSetIndex BinaryenSIMDReplaceSetValue BinaryenSIMDShuffleSetLeft BinaryenSIMDShuffleSetRight BinaryenSIMDShuffleSetMask BinaryenSIMDTernarySetOp BinaryenSIMDTernarySetA BinaryenSIMDTernarySetB BinaryenSIMDTernarySetC BinaryenSIMDShiftSetOp BinaryenSIMDShiftSetVec BinaryenSIMDShiftSetShift BinaryenSIMDLoadSetOp BinaryenSIMDLoadSetOffset BinaryenSIMDLoadSetAlign BinaryenSIMDLoadSetPtr BinaryenMemoryInitSetSegment BinaryenMemoryInitSetDest BinaryenMemoryInitSetOffset BinaryenMemoryInitSetSize BinaryenDataDropSetSegment BinaryenMemoryCopySetDest BinaryenMemoryCopySetSource BinaryenMemoryCopySetSize BinaryenMemoryFillSetDest BinaryenMemoryFillSetValue BinaryenMemoryFillSetSize BinaryenRefIsNullSetValue BinaryenRefFuncSetFunc BinaryenTrySetBody BinaryenTrySetCatchBody BinaryenThrowSetEvent BinaryenThrowSetOperandAt BinaryenThrowAppendOperand BinaryenThrowInsertOperandAt BinaryenThrowRemoveOperandAt BinaryenRethrowSetExnref BinaryenBrOnExnSetEvent BinaryenBrOnExnSetName BinaryenBrOnExnSetExnref BinaryenTupleMakeSetOperandAt BinaryenTupleMakeAppendOperand BinaryenTupleMakeInsertOperandAt BinaryenTupleMakeRemoveOperandAt BinaryenTupleExtractSetTuple BinaryenTupleExtractSetIndex BinaryenFunctionSetBody Also introduces wrappers to the JS-API resembling the classes in C++ to perform the above operations on an expression. For example: var unary = binaryen.Unary(module.i32.eqz(1)); unary.getOp(...) / .op unary.setOp(...) / .op = ... unary.getValue(...) / .value unary.setValue(...) / .value = ... unary.getType(...) / .type unary.finalize() ... Usage of wrappers is optional, and one can also use plain functions: var unary = module.i32.eqz(1); binaryen.Unary.getOp(unary, ...) ... Also adds comments to all affected functions in case we'd like to generate API documentation at some point.
* Disable nodejs warnings in test suite (#2973)rathann2020-07-221-1/+1
| | | | | | | | | | | | Fixes issue #2970 Avoids "Exception: 'run_command unexpected stderr'" when running wasm2js tests with nodejs-14.5.0+, which is due to extra warnings from that node: $ cd out/test/ $ /usr/bin/node --experimental-modules --loader /builddir/build/BUILD/binaryen-version_95/scripts/test/node-esm-loader.mjs a.2asm.mjs (node:187299) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time (Use `node --trace-warnings ...` to show where the warning was created)
* Optimize select with const arms (#2869)Max Graey2020-07-226-155/+539
| | | | | x ? 1 : 0 => !!x and so forth.
* Fix i32.trunc_f64_s of values that round up to INT32_MIN (#2975)Alon Zakai2020-07-222-4/+5
| | | See WebAssembly/spec#1224
* Add a builder.makeConst helper template (#2971)Alon Zakai2020-07-2120-173/+147
|
* Fix i32.trunc_f64_s of values near the limit of f64 representation (#2968)Alon Zakai2020-07-212-2/+4
| | | See WebAssembly/spec#1223
* Version 95 (#2967)Sam Clegg2020-07-202-1/+4
|
* wasm2js: Fix a bug with adjacent reinterprets (#2964)Alon Zakai2020-07-2020-86/+284
| | | | | | | | | | | i64 reinterprets were lowered in the i64 pass, and i32s at the very end, in wasm2js itself. This could break since in between the i64 pass and wasm2js we run optimizations, and the optimizer was not aware of what we lower the i32 reinterprets to - calls to use scratch memory. Those calls have a side effect of altering scratch memory. The optimizer just saw an i32 reinterpret, and moved it across the i64 reinterpret's scratch memory calls. This makes 32-bit reinterprets use separate scratch memory from 64-bit ones, which means they can never interfere with each other.
* Fix github actions for releases (#2965)Sam Clegg2020-07-192-14/+17
| | | | | | | Also, perform cmake --install before archive assets during normal CI builds. This means we include the binaryen shared library on platforms that use it. Fixes: #2946 #2962
* Randomize v8 JIT in fuzz_opt.py, to test both baseline and optimizing ↵Alon Zakai2020-07-171-1/+18
| | | | compilers (#2961)
* Add v128 support to instrument locals (#2960)Ng Zhi An2020-07-173-2/+34
| | | | | | In instrument-locals_all-features.wast I added the tests to the end of the file so that the diff of expected output is smaller and easier to read. Otherwise the constants will have to all change since they are order dependent.
* Interpreter: Don't change NaN bits when dividing by 1 (#2958)Alon Zakai2020-07-154-2/+54
| | | | | | | | | | | | | | | | | | It's valid to change NaN bits in that case per the wasm spec, but if we do so then fuzz testcases will fail on the optimization of nan:foo / 1 => nan:foo That is, it is ok to leave the bits as they are, and if we do that then we are consistent with the simple and valid optimization of removing a divide by 1. Found by the fuzzer - looks like on x64 on some float32 NaNs, the bits will actually change (see the testcase). I've seen this on two machines consistently, so it's normal apparently. Disable an old wasm spectest that has been updated in upstream anyhow, but the new test here is even more strict and verifies the interpreter literally changes no bits.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-07 01:20:45 +0000