Closed Bug 1428971 Opened 2 years ago Closed 2 years ago

Make wasm sign extension opcodes be controlled by their own define

Categories

(Core :: JavaScript Engine: JIT, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: lth, Assigned: lth)

Details

Attachments

(1 file)

Right now they are controlled by the threads define, but they do not depend on the threads proposal and indeed I'm trying to unbundle them from the threads proposal.  We should let them be controlled by an independent define, eg, ENABLE_WASM_SIGN_EXTENSION_OPS.
Introduce ENABLE_WASM_SIGNEXTEND_OPS and use it everywhere.  Also introduce a testing function to provide the definitive answer for whether the ops should be handled by the VM.
Attachment #8941002 - Flags: review?(bbouvier)
Comment on attachment 8941002 [details] [diff] [review]
bug1428971-control-sign-extend-ops.patch

Review of attachment 8941002 [details] [diff] [review]:
-----------------------------------------------------------------

It makes sense, thanks. If these opcodes aren't controversial at all, maybe we could even enable them by default and not have a build flag?
Attachment #8941002 - Flags: review?(bbouvier) → review+
I don't think they're controversial, but there's now some kind of proposal phasing that all proposals are going to go through (https://github.com/WebAssembly/meetings/blob/master/process/phases.md), and I expect that, as for JS spec changes, we do not want to ship anything that hasn't reached a sufficiently late stage.
Makes sense (confirming the r+).
Pushed by lhansen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/73a05a038548
Control wasm sign extension opcodes by a dedicated define. r=bbouvier
https://hg.mozilla.org/mozilla-central/rev/73a05a038548
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.