-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable WASM_BIGINT by default #22993
Conversation
Enables by default by temporarily reducing required Safari version. Also includes bugfixes for WASM_BIGINT compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't wait to see this land!
This is still WIP and has some tests and/or code under test that needs to be fixed up. I'll ping you again when it's ready or when I need other advice :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please mention this in the changelog.
@@ -34,7 +34,8 @@ var Module = typeof {{{ EXPORT_NAME }}} != 'undefined' ? {{{ EXPORT_NAME }}} : { | |||
#endif // USE_CLOSURE_COMPILER | |||
|
|||
#if POLYFILL | |||
#if WASM_BIGINT && MIN_SAFARI_VERSION < 150000 | |||
#if WASM_BIGINT && MIN_SAFARI_VERSION < 140100 | |||
// TODO(https://github.com/emscripten-core/emscripten/issues/23184): Fix this back to 150000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow these changes. This will make the polyfill be added in fewer cases - why is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point of the general messing with safari versions ( in feature_matrix itself) is to turn BIGINT on by default without affecting other features. This one here is just so that we won't default to having BIGINT on with this polyfill.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, thanks, I see. So the goal is to split out the safari version change? If so, I wonder if we can do that in this PR? The complexity of splitting it seems relatively high to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the real goal is to avoid changing all 3 settings in a single commit. But the commits also tie the settings more directly to the browser versions. So the simplest way to make enabling the features independent from each other (and independent from other consequences of raising the default version target) was to lower the version target for each feature separately (which should be a 2-line change for this feature, and 1-line for the others).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, sorry, but why was that the real goal? Naively I'd think that adjusting the browser versions would be the natural way to enable features by default, so it fits in this PR, so I'm still missing something, sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. I guess after the release we aren't really bisecting like you do with revisions, we're just testing flags to find out what breaks. So the options are testing by enabling or disabling the feature flags, or by setting the fake MIN_SAFARI version numbers and seeing what changes. But at that point the feature flags will still be there, so it's not clear to me what keeping the fake safari versions adds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. I guess after the release we aren't really bisecting like you do with revisions, we're just testing flags to find out what breaks.
Was this in reference to my mention of bisecting on MIN_SAFARI
?
If so then my point there was that if we add Safari 14.7, 14.8 etc., avoiding a single version that adds multiple features, then bisecting MIN_SAFARI
in the future becomes more useful. I agree that using the feature flags could also be done instead, but that requires one to know which flags are relevant and manually set them up, while bisecting on MIN_SAFARI
can be done by just mindless bisection on a range of numbers. Like mindless bisection on commits, that sounds useful.
Anyhow this is a minor advantage of 14.7, 14.8 imo. The larger benefit as it I see it is that once we decide on the 14.7 etc. scheme, it is permanent: we have nothing to revert in a later PR, and we have no odd things that show up during bisection that were temporary before being undone. It is a design that "smooths" out safari versions to make them incremental. If browsers enable multiple features in a single release in the future then the same idea could be used again, that is, I don't see this as a one-off hack: it is a principled approach to this problem, as I see it.
But, again, if no one else sees value in this, that's fine 😄 I'm ok with the alternative, the difference is not huge here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think mainly where we disagree is that I don't really like the idea of keeping fake browser versions around in the codebase. Bisecting on browser versions isn't really mindless if you have to know that the fake version numbers exist and what they are for, and what they can be set to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, sgtm. Maybe I like the idea of smoothing the history because it sounds like a math operation... but I agree fake versions have the downside you mention too.
I think the plan for the changelog is to make it say that the default Safari target has been raised to 15, and that includes all 3 features. This PR doesn't do that so I figured I'd update the changelog when I update the browser version. |
Maybe add a temporary entry about WASM_BIGINT and then make it more general in the followups? |
BTW it looks like all the tests here (and separate testing with the FYI tests) are now green, so once we resolve the open comment I plan to land this (assuming no new comments of course). |
Argh, expectations changes keep landing on main and causing conflicts, blocking this from merging while the tests are running :( |
Yes, sorry about that. If you know that all other tests are passing, feel free update the expections and land the PR without waiting for the tests. I do this sometimes when I know all the tests are otherwise green. |
I'll try no to land any more changes until this one goes in :) |
I just ran tools/maint/rebaseline_tests.py and it found 2 that I missed with my manual method 👍 I'll go ahead and land this. |
var low = _test_return64(0x11223344, 0xaabbccdd); | ||
var high = getTempRet0(); | ||
// Use eval to create BigInt, as no support for Xn notation yet in JS | ||
// optimizer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. how can that be true? We use the Xn
notation all over the place and run the generated code through the JS optimizer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see this code is just moving around... I guess we can update it after.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That diff is a little deceptive. What I actually did is rename testbind.js to testbind_nobigint.js and testbind_bigint.js to testbind.js. So that is just the pre-existing diff between those files.
|
||
make_fake_tool(self.in_dir('fake', 'bin', 'wasm-opt'), '70') | ||
self.check_working([EMCC, test_file('hello_world.c')], 'unexpected binaryen version: 70 (expected ') | ||
self.check_working([EMCC, test_file('hello_world.c'), '-O2'], 'unexpected binaryen version: 70 (expected ') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really good to see, since it confirms that wasm-opt doesn't run by default. Yay!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah; maybe we could even add a new test that runs various options with ERROR_ON_WASM_CHANGES_AFTER_LINK.
@@ -4,7 +4,7 @@ Note that version numbers do not necessarily reflect the amount of changes | |||
between versions. A version number reflects a release that is known to pass all | |||
tests, and versions may be tagged more or less frequently at different times. | |||
|
|||
Note that there is *no* ABI compatibility guarantee between versions - the ABI | |||
nNote that there is *no* ABI compatibility guarantee between versions - the ABI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo?
Enables by default by temporarily reducing required Safari version.
Also includes bugfixes for WASM_BIGINT compatibility.