Vendor Cranelift to get Wasm ABI-2020 support
Categories
(Core :: JavaScript: WebAssembly, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: cfallin, Assigned: cfallin)
References
Details
Attachments
(1 file)
In order to support the new Wasm ABI when using a Cranelift-based backend (bug 1657802), we need to pull in a version of Cranelift that includes PR #2223. We should be able to vendor this independently of the rest of the ABI patches, because the Cranelift-side support exists as a new ABI option.
Assignee | ||
Comment 1•4 years ago
|
||
This patch pulls in the latest version of Cranelift, which includes
necessary updates to support some recent work on the Wasm backend (e.g.,
support for the new ABI in PR #2223).
Comment 3•4 years ago
|
||
Backed outfor bustages complaining about ABIMachineSpec.
Backout link: https://hg.mozilla.org/integration/autoland/rev/449d7bd24c892aa4ab0c1498e8baa4ef698caf92
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=317343365&repo=autoland&lineNumber=27398
Assignee | ||
Comment 4•4 years ago
|
||
Hmm. This failure is due to some bitrot in an experimental new ARM32 backend in Cranelift; it appears that on the Cranelift side, the arm32
build-config feature means "new experimental backend", while on the SpiderMonkey side, we pass arm32
just to mean "hey we're on an ARM32 machine". Unfortunate overloading of this feature name loads to an inadvertent build dependency (although it appears we'd never actually invoke the Cranelift backend).
On the Cranelift side, I have a fix for the bitrot here (#2259) and I'll look into adding a build-only test to our CL/wasmtime CI. On the SpiderMonkey side, I think we should exclude Cranelift altogether on platforms that are not explicitly x86-64 or aarch64. I'll create a separate patch for that.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
bugherder |
Description
•