Emscripten upstream merge #4
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Which is how they build it upstream, and avoids some pitfalls with strings.h and the index() function (see #9506).
We normally use a JS version, which is smaller - over 1K. So I didn't want to just move us completely over to that, this is a case where not using JS APIs is a bad tradeoff for JS. And while 1K seems like not a lot, we do have a bunch more APIs like this - I can easily see us adding up to a 10K increase in small programs if we start allowing such regressions, so I think it's best avoided. A regrettable result of that is that we use different code in standalone vs normal mode. But it basically means in normal mode we optimize more for JS, which is important.
The initial landing of STANDALONE_WASM support had testing, but it was pretty hackish, just enough to get us going. This adds more proper support. This defines WASM_ENGINES in the settings file, parallel to JS_ENGINES. Adds support for running in those runtimes - in particular, we run the wasm and not the JS. Adds also_with_standalone_wasm to core, which allows us to add files to be tested in this mode. So far I added two tests. Ignore temp file leaks on /tmp/wasmer/ as it appears to add a bunch of temp files there sometimes.
Because libc++'s suffix order is `libc++-mt-noexcept`, this makes libc++abi's order the same.
Adds intrinsics and end-to-end tests for the new load instructions. These instructions are gated on `-munimplemented-simd128` for now.
The only reason this is separate is because libc is a bc file under fastcomp.
…9524) This adds testing for emcc -o X.wasm, which turns on STANDALONE_WASM.
This uses musl's getenv etc. implementations for the wasm backend, and initializes the data using the wasi APIs. This doesn't change the fastcomp implementation. There seems to be no good way to do it, as libc is bitcode, so the global ctor for this would mean it's always included, and we can't put it in libc-extras since we don't know when it's needed (e.g. libc++ might use getenv, but we don't track such internal deps, and adding hacks to the linker seems risky). So fastcomp still uses the old impl in JS. In the new upstream impl, the wasi functions call emscripten_get_environ which sets up the default env values, which are the same as before. This makes library_wasi.js always enabled, and not conditionally. This fixes a bug in our current getenv impl, which led to a test change. I also removed the test for unsetenv(0) which is an invalid use of the API and which musl does not handle.
This ensures that modules validate and are correctly emitted after WebAssembly/binaryen#2364.
And add testing that our non-wasm output does not depend on wasm. Fixes #9536
…backend (#9537) This cleans up that code and makes us only include what we need. This doesn't help builds with metadce, that removed unneeded stuff anyhow, but does help other levels, and the python code is also cleaner this way I think. It also helps a lot in modes that can't use metadce like main module (see test updates). This also uncovered a minor bug with tempRet0 which we need for dynamic linking, and wasn't being imported. Before we just happened to work since we imported all the library functions anyhow.
These looks like it used to effect test_benchmark.py but the last reference was removed in 3b24662.
We only use them to know what libraries provide, and not what they require. (For requirements, we let a library say "lib X depends on lib Y", so it doesn't actually check undefs.)
Redefine errno values to be consistent with wasi. This will let us avoid needing to convert the values back and forth as we use more wasi APIs (which I experiemented with and it adds 1K or so). This is an ABI change, which should not be noticeable from user code unless you use errno defines (like EAGAIN) and keep around binaries compiled with an older version that you link against. In that case, you should rebuild them. Fix NODEFS, which basically just routed the node errno code to ours, which only worked when the underlying system had codes similar to musl - which seems to have been the case on some linuxes. This does make NODEFS larger, as it uses the ERRNO lookup table now, I'll look into a way to avoid including it unnecessarily as a followup (would be a breaking change). Most of the changes in this PR are test changes, places where we printed raw errno codes.
…ut a fetch-worker (#9490) @dschuff looked into this and found that we can only use the fetch-worker to help with synchronous fetches when we are in a worker, since the main thread can't block on another one. But if we are in a worker, then we can just do a sync xhr directly! Thanks to that we can enable test_fetch_sync_xhr_in_wasm, so this helps #7024, but it does not fix all the cases. There is still emscripten_fetch_wait, and I believe some IDB operations may also not work. I noticed that some fetch test coverage may be misleading here, as we skip browser tests that use WASM=0 with pthreads (since wasm2js doesn't support that); I added an explicit skip to the test for emscripten_fetch_wait to make things clearer. This gets rid of a block of code starting with Should we try IndexedDB first?. That code seems unnecessary: It checks if we will need IDB and then errors if we will but it isn't ready. However, the actual operation later would error on missing IDB anyhow, so this is redundant. Worse, it looks wrong to me, as it says a simple fetch should use IDB but that doesn't seem right - in particular, it made the test here fail. Regardless, just removing the code seems best.
Musl has a bunch of such calls scattered around, so this required changes to more than 1 or 2 places. This also adds basic support for handling wasi syscall return values, which are different than musl's (which are negated). This includes the disabling of ASMFS from #9551. If we don't decide to to land that, we'd need to do more work to port ASMFS to this new syscall. This enables -Wno-unused-result on musl, as musl often calls close and ignores the result, and the wasi syscalls are marked so that they warn on that. Alternatively I can modify the wasi header? Or is there a workaround in the call site to say "ignore the value"? Separately, add stubs for mmap syscalls (I can split that out, but it's 6 lines, so seems silly, and it's next on my list).
Adding support for pre-allocating worker threads before the webassembly module is compiled. This puts the work of loading and starting up the javascript in parallel with the wasm compile, reducing overall load times. This works with the worker pool. The pool can either create + load the workers (default) or with `PTHREAD_POOL_DELAY_LOAD` it will only create them but leave loading for later. (That means that when pthreads are created the actual wasm will be loaded, but the work to create the Worker was already done earlier.)
It is a stalled work in progress, without a maintainer, and it is hard to keep it working through the syscall refactoring. See #9534
We have much better alternatives (see Changelog for details), and it was only a work-in-progress experiment.
Emscripten side of WebAssembly/binaryen#2366 (that must roll first), this tells binaryen to set the value in the wasm binary, which fixes standalone wasm module's sbrk() usage (as normally we set this is JS). This also disables eval-ctors for the wasm backend, see #9527 , which made an incorrect assumption about the sbrk initial location - JS may modify it during startup, so we can't assume it's constant. This affects only -Oz so it's probably not many users. After this PR we should be correct in both standalone and non-standalone modes, and later we can look into re-enabling eval-ctors.
In non-standalone mode we don't want assert.c, as it includes fprintf etc.
'ret' is only used inside a SUPPORT_BASE64_EMBEDDING block, but defined outside the block. Obviously a very minor change.
The underlying issue is that if crt1.o is built with WASM_OBJECT_FILES=0 then it's a bitcode file. That appears to be linked together with the user's main before the linker would create the __original_main function. As a result, the trick with making that weak doesn't work. The proposed solution here is to build crt1.o as a wasm object file in all cases. Then it's linked in at the very end, and the optimization works.
This has been ok since we made closure no longer depend on eval(), but we forgot to remove the error.
Node.js workers are workers that also HAS_NODE.
node.js doesn't have document.currentScript.src, so use __filename instead.
With the type reflection proposal, we will get a way more efficient way to convert a JS function into a wasm exported function. Use that if available.
Add a @all_engines decorator for tests to run in all possible engines, for things we want VM difference coverage for.
Fixes #9905 where it was reported that we lost our localmod that prevents always including demangling support when exceptions are enabled. This restores that, and adds size testing for exceptions and exceptions + demangling support.
(as wasm2js doesn't emit asm.js anyhow)
…s use forward slashes, even on windows (#9928)
…s use forward slashes, even on windows (part 2) (#9929)
Documents PRECISE_F32 as a fastcomp-specific setting and describes the difference with upstream backend's JS output. Resolves #9923
…set are readily supported in all browsers ( https://developer.mozilla.org/en-US/docs/Web/API/Window/pageXOffset ) (#9920)
* Make sure an invalid texture type does not propagate an invalid heap object type to WebGL, which might throw an exception? (according to #9892). * Fix webgl2_invalid_teximage2d_type.cpp test
* Micro-optimize size of _heapAccessShiftForWebGLType to be 56 bytes smaller for WebGL 2 demo. (This also might improve performance, since sparse switch cases are often implemented as binary search, although this is not in a hot code path in any way to have a difference)
* Further micro-optimize WebGL code
* Update test sizes
* Use {{{ }}} for cleaner code, and update test expectations
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.