Stack machine + 0xc update #678
Conversation
|
(commits starting with |
|
Fuzzing asm2wasm for a while also looks good. |
kripken
force-pushed
the
stack
branch
5 times, most recently
from
e0e091f
to
04c67d2
Compare
|
There is a parallel |
|
The last asm2wasm fixes here allow the emterpreter to run in wasm. In polyfill testing mode, that means that our program's code is compiled into emterpreter bytecode, which is run in the emterpreter's interpreter, which is compiled from asm.js to wasm, which is run in the polyfill wasm interpreter, which is an interpreter compiled from C++ to asm.js, which is then run in a JS engine. (The meme writes itself.) |
|
Any objections to me cleaning this up a little and landing it? The main downside is that the wasm backend and s2wasm stuff would all be disabled on master (since it's not updated yet for 0xc/stack). The upside is that this PR is big, and people are filing bugs on master that are already fixed (e.g. emscripten-core/emscripten#4531). |
|
Btw, I ran csmith fuzzing on the asm2wasm path on this branch for 4 days, and found just one minor bug (when running asm2wasm itself compiled to JS, which we do for testing but users would normally run asm2wasm natively, which works ok). |
|
I think I'm almost ready for this. The waterfall has been a bit chaotic lately. Right now the standalone (non-emscripten) tests are running with a frozen version of binaryen to test v8's native wasm mode, so they won't be affected. I'm about to land https://reviews.llvm.org/D24053 which fixes several tests. Currently though the emscripten build on the waterfall is actually broken because of the build warning that @aheejin reported in emscripten-core/emscripten#4501. So maybe we should fix that and get it building again before landing this? Shouldn't be too hard, I'll look into it. |
|
Sounds good. I commented in that issue now with one possible quick fix. |
|
Rebased, cleaned up a little, and re-enabled spec tests on latest upstream |
|
Spec repo now has a PR with the new import/export stuff with a concrete syntax, which differs from the temporary one I guessed here. Added a commit for imports now. |
kripken
force-pushed
the
stack
branch
2 times, most recently
from
11b45e1
to
0dcef5e
Compare
|
@dschuff, ping - are you ok with this landing? Meanwhile I did some more parsing work here for upcoming spec repo changes. |
|
I think so. Is it still the case that s2wasm/wasm backend is completely disabled? I guess what we have to do is just update the wasm building code in s2wasm, so that it builds the new IR? |
|
Yes, in this PR that's disabled. There are the handwritten and autogenerated tests etc. that need to be fixed up, unless you've already done that? If not, what do you think about landing this first? |
|
Anyone know why appveyor keeps failing? There isn't a build to check an error on, weird. |
|
@dschuff: ping - are you ok to land this? (needs a merge fix which I'll fix, and later on master we can figure out the .s/wasm-backend tests) |
|
Yeah, go ahead and land it. Thanks for the heads-up. On Tue, Sep 6, 2016, 4:45 PM Alon Zakai notifications@github.com wrote:
|
…ay invalidate the branch
… input is not yet valid then after finalizeCalls, we must autodrop again to drop things that finalizeCalls changed
apply memory segments only if there isn't a memory initializer (which we need for asmjs and asm2wasm modes) use wasm-opt to check recreated wasts for validity, as wasm-shell would try to execute them add testing for combined modes like asmjs,interpret-binary
…ts whose return value is polymorphic
|
Ok, rebased and tests passed, merging. |
This brings in all the 0xc and stack machine stuff that are on the spec repo's
stackbranch. At this point thisSo it's basically done from my point of view, and if anyone wants to review this now is a good time. However, disabled are