| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
The new asyncify flag --pass-arg=asyncify-propagate-addlist changes the
behavior of --pass-arg=asyncify-addlist : with it, callers of functions in the
asyncify-addlist will be also instrumented.
|
| |
|
|
|
| |
Avoid some common warnings and stop printing various stdout/stderr stuff.
Helps #6104
|
| |
|
| |
Followup to #4108
|
| |
|
|
|
|
| |
This PR contains:
- Changes that enable/disable tests on Windows to allow for better local testing.
- Also changes many abort() into Fatal() when it is really just exiting on error. This is because abort() generates a dialog window on Windows which is not great in automated scripts.
- Improvements to CMake to better work with the project in IDEs (VS).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us run most tests at least on that platform.
Add a new function for skipping those tests, skip_if_on_windows,
so that it's easy to find which tests are disabled on windows for later fixing
efforts.
This fixes a few minor issues for windows, like comparisons
should ignore \r in some cases.
Rename all passes tests that use --dwarfdump to contain "dwarf"
in their name, which makes it easy to skip those (and is clearer
anyhow).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Asyncify does a whole-program analysis to figure out the list of functions
to instrument. In
emscripten-core/emscripten#10746 (comment)
we realized that we need another type of list there, an "add list" which is a
list of functions to add to the instrumented functions list, that is, that we
should definitely instrument.
The use case in that link is that we disable indirect calls, but there is
one special indirect call that we do need to instrument. Being able to add
just that one can be much more efficient than assuming all indirect calls in
a big codebase need instrumentation. Similar issues can come up if we
add a profile-guided option to asyncify, which we've discussed.
The existing lists were not good enough to allow that, so a new option
is needed. I took the opportunity to rename the old ones to something
better and more consistent, so after this PR we have 3 lists as follows:
* The old "remove list" (previously "blacklist") which removes functions
from the list of functions to be instrumented.
* The new "add list" which adds to that list (note how add/remove are
clearly parallel).
* The old "only list" (previously "whitelist") which simply replaces the
entire list, and so only those functions are instrumented and no other.
This PR temporarily still supports the old names in the commandline
arguments, to avoid immediate breakage for our CI.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We assumed that the imports were already named (in their
internal name) properly. When processing a binary file without
names, or if the names don't match in general, that's not true.
To fix this, use ModuleUtils::renameFunctions to do a proper
renaming up front.
Also fix renameFunctions to not assert on the case of
renaming a function to the same name it already has.
Helps #2680
|
| | |
|
| |
|
|
|
| |
Don't directly import names from shared.py and support.py, and use
prefixes instead. Also this reorders imports based on PEP
recommendation.
|
| |
|
|
|
|
|
|
| |
If wasm-opt is run with no passes, warn, as we've gotten reports that people
assume a tool called "wasm-opt" should optimize automatically (but we follow
llvm's opt convention of not doing so).
Add a --quiet (-q) flag that suppresses this minor warning, and the other minor
warning where there is no output file.
|
| |
|
| |
See emscripten-core/emscripten#9381 for rationale.
|
| |
|
| |
See emscripten-core/emscripten#9206, the asyncify names can need complex escaping, so this provides an escape hatch.
|
| |
|
|
|
|
|
|
| |
pep8 specifies 4 space indentation. The use of 2 spaces is, I believe
a historical anomaly where certain large organizations such as google
chose 2 over 4 and have yet to make the switch.
Since there isn't too much code in binaryen today it seems reasonable to
make the switch.
|
| |
|
|
|
| |
The lists are comma separated, but the names can have internal commas since they are human-readable. This adds awareness of bracketing things, so void foo(int, double) is parsed as a single function name, properly.
Helps emscripten-core/emscripten#9128
|
| |
|
|
|
| |
I fixed flatten.bin.txt which seems to have just had some corrupted data, and I removed some fancy unicode from the spec comments tests, which I'm not sure it's important enough to figure out how to fix.
Fixes #1691
|
| |
|
|
|
|
|
|
|
| |
The blacklist means "functions here are to be ignored and not instrumented, we can assume they never unwind." The whitelist means "only these functions, and no others, can unwind." I had hoped such lists would not be necessary, since Asyncify's overhead is much smaller than the old Asyncify and Emterpreter, but as projects have noticed, the overhead to size and speed is still significant. The lists give power users a way to reduce any unnecessary overhead.
A slightly tricky thing is escaping of names: we escape names from the names section (see #2261 #1646). The lists arrive in human-readable format, so we escape them before comparing to the internal escaped names. To enable that I refactored wasm-binary a little bit to provide the escaping logic, cc @yurydelendik
If both lists are specified, an error is shown (since that is meaningless). If a name appears in a list that is not in the module, we show a warning, which will hopefully help people debug typos etc. I had hoped to make this an error, but the problem is that due to inlining etc. a single list will not always work for both unoptimized and optimized builds (a function may vanish when optimizing, due to duplicate function elimination or inlining).
Fixes #2218.
|
|
|
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.
|
