Inline paths for memory.copy and memory.fill on wasm memory64
Categories
(Core :: JavaScript: WebAssembly, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox100 | --- | fixed |
People
(Reporter: lth, Assigned: lth)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
The initial landing of memory64 only supports out-of-line code for memory.copy and memory.fill, but we would want in-line code for these just as we have on 32-bit memories.
On 64-bit systems the code may operate above the 4GB limit and real work may be required to implement.
On 32-bit it'll stay below the 2GB limit, so this would amount to just executing a 64-bit bounds check and then use the existing in-line code as-is.
|
Assignee | |
Comment 1•3 years ago
|
||
A drive-by issue that might be worth considering at the same time is that the inline vs call cutoff is probably different for shared memory since we use our own memcpy for shared memory, see also bug 1737840.
On the main subject, it looks like the Ion code generalizes quite easily to 64 bits, should not be hard to implement this.
|
|
Assignee | |
Comment 2•3 years ago
|
||
A completely straightforward adaptation of existing code for 32-bit.
I opted not to do this for baseline, indeed I think that the implementation
of this for baseline on mem32 was a bridge too far. Discuss.
|
||
Updated•3 years ago
|
Pushed by lhansen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8f6f5f4cc1ec inline memory.copy and memory.fill in ion for memory64. r=rhunt
|
||
Comment 4•3 years ago
|
||
| bugherder | ||
Description
•