Closed Bug 1737266 Opened 7 months ago Closed 2 months ago

Inline paths for memory.copy and memory.fill on wasm memory64

Categories

(Core :: Javascript: WebAssembly, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
100 Branch
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.

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.

Depends on: 1739971

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.

Assignee: nobody → lhansen
Status: NEW → ASSIGNED
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
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
You need to log in before you can comment on or make changes to this bug.