Wasm/JS BigInt support #10860
Wasm/JS BigInt support #10860
Conversation
| @@ -3128,6 +3128,9 @@ def legalize_sig(sig): | |||
|
|
|||
| @staticmethod | |||
| def is_legal_sig(sig): | |||
| # with BigInt support all sigs are legal since we can use i64s. | |||
| if Settings.WASM_BIGINT: | |||
There was a problem hiding this comment.
Should legalize_sig be changed to return sig if WASM_BIGINT? That would make this still correct, and handle any other places we'd want the legalized signature
There was a problem hiding this comment.
Looks like this is not necessary, since the only callsite is already checking LEGALIZE_JS_FFI before calling.
Replace with assert not Settings.WASM_BIGINT?
There was a problem hiding this comment.
I think @jgravelle-google is right, since there is another call site to there, so this code path is actually taken with bigints. I missed this in testing since the existing tests happen to not check it carefully enough. Fixed + added a test now, thanks!
There was a problem hiding this comment.
But where is the other callsite? I only see one.
There was a problem hiding this comment.
legalize_sig is called from is_legal_sig and also make_invoke. The latter path was not handled properly and we emitted slightly incorrect invoke code.
There was a problem hiding this comment.
is_legal_sig is looks like its only called from emscripten.py:create_fp_accessors
So can't is_legal_sig just do assert not Settings.WASM_BIGINT since calling this when WASM_BIGINT should never happen.
There was a problem hiding this comment.
Ah, so there are two issues here.
The function @jgravelle-google and I were talking about is legalize_sig. That's not the function this discussion is tacked on to, it's the function @jgravelle-google mentioned we might be missing (and we were).
You are right about is_legal_sig, but I think instead of an assertion it's easy to just do the right behavior as the patch already does? Seems clearer, and ready if we need it later.
There was a problem hiding this comment.
Oh wait, no, is_legal_sig is called from emscripten.py there, yeah. So we can't assert, we have to do what the patch already does.
There was a problem hiding this comment.
Oh heh, no, that was wrong, ignore the last comment.
| @@ -1390,7 +1390,9 @@ var SyscallsLibrary = { | |||
| FS.utime(path, atime, mtime); | |||
| return 0; | |||
| }, | |||
| __sys_fallocate: function(fd, mode, off_low, off_high, len_low, len_high) { | |||
| __sys_fallocate: function(fd, mode, {{{ defineI64Param('off') }}}, {{{ defineI64Param('len') }}}) { | |||
There was a problem hiding this comment.
I can't tell whether this is gross or not.
Either way I like it :)
| @@ -2007,6 +2007,9 @@ def check_human_readable_list(items): | |||
| # requires JS legalization | |||
| shared.Settings.LEGALIZE_JS_FFI = 0 | |||
|
|
|||
| if shared.Settings.WASM_BIGINT: | |||
| shared.Settings.LEGALIZE_JS_FFI = 0 | |||
There was a problem hiding this comment.
Is legalization only dealing with the i64 issue?
There was a problem hiding this comment.
We used to legalize f32s to doubles for JS too, but it turned out that was not necessary. So it is just i64s now, yes.
| @@ -3128,6 +3128,9 @@ def legalize_sig(sig): | |||
|
|
|||
| @staticmethod | |||
| def is_legal_sig(sig): | |||
| # with BigInt support all sigs are legal since we can use i64s. | |||
| if Settings.WASM_BIGINT: | |||
There was a problem hiding this comment.
Looks like this is not necessary, since the only callsite is already checking LEGALIZE_JS_FFI before calling.
Replace with assert not Settings.WASM_BIGINT?
|
I worry |
This adds a flag
WASM_BIGINTwhich enables this feature, withwhich we let the JS VM use a JS BigInt for a wasm i64. In that case
we don't need to legalize i64s into pairs of i32s.
This is fairly straightforward, but we do need to modify the JS code
of each library method that receives or returns an i64.
Tests verify that we can send and receive i64s from wasm to JS,
and also that a dynCall works. This depends on
WebAssembly/binaryen#2726 for that.