| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
(#2242)
Main change here is in pass.h, everything else is changes to work with the new API.
The add("name") remains as before, while the weird variadic add(..) which constructed the pass now just gets a std::unique_ptr of a pass. This also makes the memory management internally fully automatic. And it makes it trivial to parallelize WalkerPass::run on parallel passes.
As a benefit, this allows removing a lot of code since in many cases there is no need to create a new pass runner, and running a pass can be just a single line.
|
| | |
|
| |
|
|
|
| |
The key thing is that there is a single constant, which may or may not be saved/loaded from a local, and may or may not get an added global if in relocatable code.
Fixes emscripten-core/emscripten#8993
|
| |
|
|
|
| |
* Clarify the difference between old and new Asyncify.
* Remove the old --bysyncify pass option.
|
| | |
|
| |
|
|
|
|
|
| |
After some discussion this seems like a less confusing name: what the pass does is "asyncify" code, after all.
The one downside is the name overlaps with the old emscripten "Asyncify" utility, which we'll need to clarify in the docs there.
This keeps the old --bysyncify flag around for now, which is helpful for avoiding temporary breakage on CI as we move the emscripten side as well.
|
| |
|
|
| |
In WebAssembly/exception-handling#79 we agreed to rename `except_ref`
type to `exnref`.
|
| |
|
| |
We don't ever emit "use asm" anymore, so this similar annotation is not really useful, it just increases size.
|
| | |
|
| |
|
| |
This became noticeable after #2216 which led to some eqz eqz pairs in the test suite.
|
| |
|
| |
This can't use the normal wasm-opt mechanism because we modify the discard the wasm as part of running wasm2js, so we need to emit it in the proper place in the middle.
|
| |
|
|
|
|
|
| |
An if whose body is a br_if can be turned into a br_if of a combined condition (if side effects allow it).
The naive size in bytes is identical between the patterns, but the select may avoid a hardware branch, and also the select may be further optimized. On the benchmark suite this helps every single benchmark, but by quite small amounts (e.g. 100 bytes on sqlite, which is 1MB).
This was noticed in emscripten-core/emscripten#8941
|
| |
|
| |
This is core import like __memory_base and __table_base.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I'm working on a change to lld that will cause `-pie` binaries to
import __stack_pointer, just like -shared do already. Because we
don't yet support mutable globals everywhere this change will
internalize the import and create a new immutable import that is used
to initialize the internal one.
This change is part of the fix for:
https://github.com/emscripten-core/emscripten/issues/8915
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We were passing bad value in --initial-stack-pointer which did not
include the STATIC_BUMP (since STATIC_BUMP is determinted by the output
of finalize).
If emscripten wants to set the stack pointer position it can do
so by calling the stackRestore() function at startup.
This argument will be removed completely once we stop passing it on the
emscripten side.
See https://github.com/emscripten-core/emscripten/issues/8905
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct FooPass : public wasm::Pass {
FooPass(int a, int b);
};
PassRunner runner {module};
runner.add<FooPass>(1, 2); // To allow this
This change avoids unnecessary copying and allows us to pass the reference without reference_wrapper.
struct BarPass : public wasm::Pass {
BarPass(std::ostream& s);
};
runner.add<BarPass>(std::cout); // Error (cout is uncopyable)
runner.add<BarPass>(std::ref(std::cout)); // OK
↓
runner.add<BarPass>(std::cout); // OK (passed by reference)
runner.add<BarPass>(std::ref(std::cout)); // OK
|
| | |
|
| |
|
|
| |
instructions (#2199)
|
| |
|
|
|
|
|
|
|
|
|
| |
Including parsing, printing, assembling, disassembling.
TODO:
- interpreting
- effects
- finalization and typing
- fuzzing
- JS/C API
|
| |
|
|
| |
Allow MemoryPacking to run when there are no passive segments, even if
bulk memory is enabled.
|
| |
|
|
|
| |
Fix and test mutable globals support, replace string literals with
constants, and add a pass to emit the target features section.
|
| |
|
|
|
|
|
| |
This is the first stage of adding support for stacky/multivaluey things. It adds new push/pop instructions, and so far just shows that they can be read and written, and that the optimizer doesn't do anything immediately wrong on them.
No fuzzer support, since there isn't a "correct" way to use these yet. The current test shows some "incorrect" usages of them, which is nice to see that we can parse/emit them, but we should replace them with proper usages of push/pop once we actually have those (see comments in the tests).
This should be enough to unblock exceptions (which needs a pop in try-catches). It is also a step towards multivalue (I added some docs about that), but most of multivalue is left to be done.
|
| |
|
| |
Previously we tried to export it if the memory was exported, even if growth was not on, which caused an error.
|
| |
|
|
|
|
| |
The event section should be between the global section and the export
section, if present. Here tests are missing, but we don't have a very
good way of testing validity of binary anyway. We are planning to add d8
tests in a separate PR.
|
| |
|
|
|
| |
Add assertions on stack overflow in all 4 Bysyncify API calls (previously only 2 did it).
Also add a check that those assertions are hit.
|
| |
|
|
|
|
|
| |
(#2191)
Keep limiting in precompute as before: that is useful since that pass is run as part of normal compilation, and we want to avoid native stack limits on all platforms. Also that pass is not likely to find any pattern of size 50 of higher that it can't precompute as a sum of smaller pieces.
Restore the 250 limit from before for interpreting entire modules, as without that the fuzzer will sometimes hit the limit and cause a false positive.
|
| |
|
|
|
|
|
|
| |
Gets fuzzing support for Bysyncify working.
* Add the python to run the fuzzing on bysyncify.
* Add a JS script to load and run a testcase with bysyncify support. The code has all the runtime support for sleep/resume etc., which it does on calls to imports at random in a deterministic manner.
* Export memory from fuzzer so JS can access it.
* Fix tiny builder bug with makeExport.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Workaround for wasm2js output minification issue with emscripten
When using emscripten with -O2 and --memory-init-file 0, the
JS minification breaks on this function for memory initialization
setup, causing an exception to be thrown during module setup.
Moving from two 'var' declarations for the same variable to one
should avoid hitting this with no change in functionality (the
var gets hoisted anyway).
https://github.com/emscripten-core/emscripten/issues/8886
|
| |
|
| |
As decided in the recent in-person CG meeting.
|
| |
|
| |
This allows us to do things in emscripten like note that all env.invoke_* functions are important.
|
| |
|
|
|
| |
We assigned it to a local, but didn't run maybeSkip on it. As a result, it was executed during rewinding, which broke restoring the saved value.
Found by the fuzzer.
|
| | |
|
| |
|
|
|
| |
We need memory in order to read and write rewinding info, so add it if the module didn't have any memory at all.
Found by the fuzzer.
|
| |
|
|
|
|
|
|
|
| |
(#2183)
This results in better code sizes on many testcases, sometimes much better. For example, on SQLite the 150K function has only 27 locals instead of 3,874 which it had before (!). This also reduces total code size on SQLite by 15%.
The key issue is that after instrumenting control flow we have a lot bigger live ranges.
This must be done rather carefully, as we need to introduce some temp locals early on (for breaking up ifs, for call return values, etc.).
|
| |
|
|
| |
This prevents RemoveImports from producing an invalid module that
references functions that no longer exist.
|
| |
|
|
|
| |
Those functions are assumed to be part of the runtime. Instrumenting them would mean nothing can work.
With this fix, bysyncify is useful with pure wasm, and not just through imports.
|
| |
|
| |
ignore-imports makes it not assume that any import may unwind/rewind the stack. ignore-indirect makes it not assume any indirect call can reach an unwind/rewind (which means, it assumes there is not an indirect call on the stack while unwinding).
|
| |
|
|
| |
Otherwise there is no way to view a wasm object file in binaryen.
|
| |
|
| |
Add a method to note the stopping of an unwind. This is enough to implement coroutines. Includes an example of coroutine usage in the test suite.
|
| |
|
|
|
|
|
|
|
| |
This adds a new pass, Bysyncify, which transforms code to allow unwind and rewinding the call stack and local state. This allows things like coroutines, turning synchronous code asynchronous, etc.
The new pass file itself has a large comment on top with docs.
So far the tests here seem to show this works, but this hasn't been tested heavily yet. My next step is to hook this up to emscripten as a replacement for asyncify/emterpreter, see emscripten-core/emscripten#8561
Note that this is completely usable by itself, so it could be useful for any language that needs coroutines etc., and not just ones using LLVM and/or emscripten. See docs on the ABI in the pass source.
|
| |
|
|
|
|
| |
* Fix BinaryenRemoveEvent naming in binaryen-c.h
* Enable ERROR_ON_UNDEFINED_SYMBOLS=1 in build-js.sh
|
| |
|
| |
_ISOC11_SOURCE is the preprocessor flag that specifies whether or not aligned_alloc is defined and exists. While GCC versions lower than 5 do include C++11 and C++14 constructs, they do not include std::aligned_alloc, so this check allows compiling on those versions of GCC by defaulting down to posix_memalign in those situations appropriately.
|
| |
|
|
|
| |
Use one shared location in optimization-options as much as possible.
This also allows tools like wasm2js to receive that flag.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes in Relooper merge consecutive blocks:
Entry block getting removed when it is part of a loop:
bb1->AddBranchTo(bb2, nullptr);
bb1->AddBranchTo(bb3, ...);
bb2->AddBranchTo(bb1, nullptr);
bb3->AddBranchTo(bb4, nullptr);
relooper.AddBlock(bb1);
relooper.AddBlock(bb2);
relooper.AddBlock(bb3);
relooper.AddBlock(bb4);
relooper.Calculate(bb1);
Branches memory leak
|
| |
|
|
|
| |
This prevents the optimizer from producing v128.const instructions,
which are not supported by V8 at this time.
|
| |
|
|
|
|
|
| |
This should be small enough to work in a 512K stack on Linux, which may then be small enough to work on all common OSes.
I had to update some spec tests which actually did more recursive calls, but I don't think the change reduces any relevant amount of test coverage.
This may fix the Mac bot finally, as with this it passes for me on the stack size I think Macs have by default.
|
| | |
|
| |
|
|
|
| |
We previously had one for calls (the spec tests check for infinite recursion).
This is an internal limit of the interpreter, until we un-recursify it, which may make sense at some point - but it's unlikely interpreting massively-recursive things will be beneficial in the optimizer anyhow, since if it could do something with them, it could also do so on the smaller pieces iteratively.
|
