[WASM-References] Add support for memory.fill
Created attachment 416145 [details] Patch
This patch modifies one of the wasm.json files. Please ensure that any changes in one have been mirrored to the other. You can find the wasm.json files at "Source/JavaScriptCore/wasm/wasm.json" and "JSTests/wasm/wasm.json".
Comment on attachment 416145 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416145&action=review Looks good. Some comments. > Source/JavaScriptCore/ChangeLog:8 > + Added spec tests and unreachable tests for memory.fill. Can you put this to JSTests/ChangeLog side? > Source/JavaScriptCore/wasm/WasmMemory.cpp:624 > + auto locker = holdLock(m_handle->lock()); I don't think we need this locking. When size is updated, mprotect is already done (because mprotect has memory barrier). So, if `if (offset + count > m_handle->size())` pass, then we can just perform this without taking a lock. So, I think we can just remove `doMemoryFill` function, and merge it into `Memory::fill`. > Source/JavaScriptCore/wasm/WasmMemory.cpp:633 > + if ((unsafeOffset < 0) || (unsafeCount < 0)) > + return false; Is it correct? I'm looking into https://webassembly.github.io/bulk-memory-operations/core/exec/instructions.html#exec-memory-fill, but I cannot find the corresponding thing. Should we just handle unsafeOffset and unsafeCount as uint32_t instead? > Source/JavaScriptCore/wasm/WasmSlowPaths.cpp:387 > + int32_t dstAddress = READ(instruction.m_dstAddress).unboxedInt32(); > + int32_t targetValue = READ(instruction.m_targetValue).unboxedInt32(); > + int32_t count = READ(instruction.m_count).unboxedInt32(); If they should be handled as uint32, let's add unboxedUInt32 and use it (this is just `static_cast<uint32_t>(unboxedInt32())`). > JSTests/ChangeLog:10 > + Add support for memory.fill from ref-types spec. > + memory.fill sets all bytes in a memory region to a given byte: > + https://webassembly.github.io/reference-types/core/syntax/instructions.html#memory-instructions. Can you put this to JavaScriptCore/ChangeLog side?
Comment on attachment 416145 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416145&action=review >> Source/JavaScriptCore/wasm/WasmMemory.cpp:624 >> + auto locker = holdLock(m_handle->lock()); > > I don't think we need this locking. When size is updated, mprotect is already done (because mprotect has memory barrier). > So, if `if (offset + count > m_handle->size())` pass, then we can just perform this without taking a lock. > So, I think we can just remove `doMemoryFill` function, and merge it into `Memory::fill`. Note that, if the memory mode is MemorySharingMode::Shared, underlying memory never gets replaced. mprotect will just extend it if memory grows.
Created attachment 416226 [details] Patch
Comment on attachment 416226 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416226&action=review r=me with comment. > Source/JavaScriptCore/wasm/WasmOperations.cpp:641 > +JSC_DEFINE_JIT_OPERATION(operationWasmMemoryFill, bool, (Instance* instance, uint32_t dstAddress, int32_t targetValue, uint32_t count)) Change `int32_t targetValue` to `uint32_t`. > Source/JavaScriptCore/wasm/WasmOperations.h:64 > +JSC_DECLARE_JIT_OPERATION(operationWasmMemoryFill, bool, (Instance*, uint32_t dstAddress, int32_t targetValue, uint32_t count)); Ditto.
Created attachment 416233 [details] Patch
Committed r270855: <https://trac.webkit.org/changeset/270855> All reviewed patches have been landed. Closing bug and clearing flags on attachment 416233 [details].
<rdar://problem/72349990>